Ascent Technology’s argument that “AI readiness is data readiness” is directionally right for Microsoft 365 Copilot, but its August 4 ITWeb piece leaves out two operational facts that matter more to an administrator than the slogan: Copilot inherits existing access decisions rather than repairing them, and one of the temporary controls it recommends can no longer be newly enabled. The article, issued by Ascent Technology rather than reported independently by ITWeb, arrives after Investec announced on June 24 that it had rolled out Microsoft Copilot to all 8,000 employees globally. Investec says more than 800 AI agents are in use and estimates more than 350,000 hours of annual capacity from its AI systems. Those are company claims, not independently audited productivity results, but the deployment is a real marker of how quickly Copilot discussions have moved from small pilots to estate-wide planning.
For Windows and Microsoft 365 administrators, the useful conclusion is narrower than Ascent’s sales-adjacent framing: a Copilot rollout is first an identity, permissions, content-lifecycle, and information-protection project. Licensing is easy. Establishing who can see which SharePoint site, Teams file, mailbox, OneDrive document, and connected business system is the work.
Microsoft’s own current deployment guidance supports that sequence. Its secure-and-governed Copilot blueprint begins with remediating oversharing, then implementing guardrails, then meeting regulatory requirements. That is an unusually direct acknowledgement from the vendor that Copilot’s usefulness and its exposure both depend on the tenant it is connected to.

A cybersecurity analyst monitors data integrations, alerts, and document workflows across multiple screens.Copilot Respects Permissions — Including Bad Ones​

Microsoft 365 Copilot accesses organizational content through the signed-in user’s existing permissions. In practical terms, it can ground responses in content from Microsoft Graph workloads such as Exchange, SharePoint, OneDrive, Teams, calendar data, and files the user is allowed to reach. Microsoft is explicit that Copilot does not grant a user new access to content they were previously barred from opening.
That is a security property, but it is not a guarantee that the answer Copilot produces is safe to disclose or safe to act upon.
A user may already have technically valid access to a broad SharePoint site through an old “Everyone except external users” group, a legacy SharePoint permission inheritance chain, a stale project team, a broadly shared Excel workbook, or a OneDrive link that was never withdrawn. Before Copilot, finding the sensitive document may have required knowing where it lived or manually searching a folder tree. With Copilot, the same user can ask a natural-language question that spans documents, chats, and email. The access decision has not changed; the discoverability and speed of synthesis have.
That is why “Copilot creates oversharing” is the wrong diagnosis. It more often makes pre-existing oversharing visible and usable. The distinction matters for remediation. Turning Copilot off does not repair a permissive tenant; it merely removes one especially efficient way for employees to encounter content they could already access.
The article is also too absolute in saying Copilot “arrives knowing nothing about your business.” A Microsoft 365 Copilot response can be grounded in tenant data, but the underlying large language model retains broad pretrained knowledge. More importantly, the modern Copilot surface is no longer limited to the core Microsoft 365 estate. Agents and connectors can introduce approved external data sources and actions. The right question is therefore not merely, “What files can Copilot read?” It is: Which identities, sources, agents, and actions are in scope for this use case?
A finance Copilot agent attached to a data warehouse presents a different risk profile from a Word drafting use case grounded in the user’s current document. Treating both as a generic “Copilot rollout” obscures the controls each needs.

The Restricted SharePoint Search Advice Is Already Outdated​

The most material omission in Ascent’s article is its treatment of Restricted SharePoint Search, or RSS. It correctly describes RSS as a temporary measure rather than a true security boundary. Microsoft’s documentation goes further: RSS is retiring, and new enablement was blocked on July 31, 2026 — four days before the August 4 article was published.
Existing RSS deployments have not suddenly become meaningless. But an organization that did not already enable it cannot now make RSS its late-stage Copilot pilot plan. This is not a minor product-note detail. RSS had often been positioned as a practical stopgap for organizations that wanted to restrict tenant-wide search and Copilot discovery to an allow list of reviewed SharePoint sites while site owners worked through permissions.
Even when it was available for new deployment, RSS had hard limitations. It did not change SharePoint permissions. It did not prevent users from seeing content they owned, recently accessed, or received through Teams or Outlook. It was limited to a curated group of sites and could make search and Copilot answers less comprehensive. Microsoft has consistently said it was intended to buy time for cleanup, not substitute for cleanup.
Microsoft’s replacement direction is toward more durable controls: Restricted Content Discovery for limiting content discovery, Restricted Access Control for enforcing access to particular SharePoint sites, SharePoint Advanced Management for identifying broad access and inactive content, and Microsoft Purview for sensitivity labels, data loss prevention, auditing, and AI-focused data security posture management.
Administrators should not read that as a reason to delay deployment until every legacy site is immaculate. No large tenant reaches a permanently “clean” state. It does mean a rollout plan built around RSS needs to be rewritten now. Use cases should be launched against defined, reviewed data domains rather than opening the entire estate and hoping a temporary search filter absorbs the risk.

Data Quality Is a Separate Failure Mode​

Permissions determine what Copilot may retrieve. Data quality determines whether the retrieved material deserves to be trusted.
Ascent is on firm ground when it warns that outdated, duplicated, poorly labelled, or incomplete business content can generate answers that sound polished while being wrong. Microsoft’s own Copilot guidance makes similar warnings in its data preparation material: poorly prepared data can produce generic, inaccurate, or misleading results.
The operational trap is that access governance and information quality are often owned by different teams. Identity may belong to IT, SharePoint governance to collaboration services, records retention to legal, classification to compliance, business definitions to finance or data teams, and agent design to a new AI center of excellence. Copilot crosses all of those boundaries in a single prompt.
Consider an employee asking for the current travel-expense policy. If the tenant contains a superseded PDF, an unofficial departmental version, a draft policy in a Teams channel, and the final signed-off version in a records library, a response may cite any material that is relevant enough to retrieve and accessible enough to use. A citation shows where the text came from. It does not establish that the cited document is current policy.
This is where the “data readiness” thesis needs a practical translation. Do not start with a multi-year campaign to classify every file in the company. Start with the data that each approved Copilot scenario will access, identify its authoritative source, verify retention and ownership, remove or restrict clearly obsolete material, and make the approved source easier to find than the debris around it.
For Windows administrators, that work extends beyond SharePoint. Conditional Access, MFA, device compliance, session controls, privileged-role assignments, Entra group hygiene, guest access, and offboarding all remain relevant because Copilot operates through the identity and authorization fabric already in place. A user with a compromised session and excessive permissions does not become less dangerous because Copilot honors those permissions faithfully.

POPIA Does Not Move Accountability to Microsoft​

The South African part of Ascent’s argument is also substantially correct: POPIA makes a responsible party accountable for lawful processing of personal information. Microsoft can provide a service boundary, technical controls, audit capabilities, and contractual commitments, but the organization deciding why and how personal information is processed cannot outsource its accountability to a Copilot license.
That does not mean every Copilot response involving personal information is automatically a POPIA breach. It does mean organizations need to be able to explain the purpose, authority, access controls, retention position, and safeguards around the processing. An AI-generated summary of employee, client, health, financial, or disciplinary data is still processing. The fact that a user received the material through a chat interface does not make the underlying decision trail disappear.
Data residency can be important for contractual and regulatory reasons, but it is not the same as data governance. Processing content inside a South African region does not fix a file that is shared too broadly, a data subject record that is inaccurate, or a policy that lacks a defensible retention basis.

A Rollout Plan That Survives Contact With the Tenant​

A credible Microsoft 365 Copilot rollout should be measured less by enabled seats than by whether the organization can support specific workloads safely and repeatably.
  • Inventory the intended Copilot use cases and identify the exact Microsoft 365 and external data sources each one can reach.
  • Run SharePoint and OneDrive access-governance reporting before broad enablement, with priority given to sites carrying HR, finance, legal, executive, customer, and regulated content.
  • Replace broad sharing where it has no current business purpose with group-based access and named ownership, then verify the behavior using ordinary user accounts rather than administrator assumptions.
  • Apply sensitivity labels, data loss prevention, retention, and audit controls to the content types that matter to the selected use cases.
  • Treat each Copilot agent as an application integration with its own data sources, identity model, permissions, owner, change process, and logging requirements.
  • Test response quality against known authoritative documents and deliberately ambiguous or stale content before claiming that an agent is ready for production.
Investec’s rollout shows that full-workforce Copilot deployment is now possible in a regulated organization. It does not prove that every organization should replicate the speed of that rollout, nor does it validate the productivity figures that accompanied its announcement. What it does show is that the market has entered the phase where access sprawl, stale content, and unclear ownership stop being background IT debt and become direct constraints on AI adoption.
The immediate change for teams still planning a pilot is straightforward: do not design around Restricted SharePoint Search, because new enablement has been blocked since July 31, 2026. Build around durable access controls, curated use cases, and verified authoritative data. Copilot will amplify whatever foundation it is given; the administrator’s job is to ensure that foundation is one the organization can defend.

References​

  1. Primary source: ITWeb
    Published: 2026-08-04T06:42:00+00:00
  2. Related coverage: learn.microsoft.com
  3. Related coverage: learn.microsoft.com
  4. Related coverage: ico.org.uk
  5. Related coverage: ico.org.uk
  6. Related coverage: techradar.com