• Introduction: Understanding device readiness and lifecycle
• Chapter 1: Plan and standardize
• Chapter 2: Acquire
• Chapter 3: Onboard
• Chapter 4: Operate
• Chapter 5: Optimize
• Chapter 6: Refresh or reassign
• Chapter 7: Retire
• Conclusion

In a global organization such as Microsoft—with more than 220,000 employees connecting and working together from offices and remote workspaces scattered around the world—we enable our workers to stay productive from almost anywhere, on a wide range of devices.

At Microsoft Digital, the company’s IT organization, we provide our employees with that flexibility while helping keep the devices they use secure, compliant, and supportable at enterprise scale.

“Every digital experience depends on the readiness of the devices our employees use every day. Organizations that treat device management as a strategic lifecycle capability rather than a series of operational tasks are better positioned to adapt to change, reduce risk, and take advantage of new innovations with confidence.”

Brian Fielder, vice president, Microsoft Digital

We balance employee experience, security posture, and operational efficiency as part of modern device management.

This IT playbook explains how we think about device readiness at Microsoft Digital, where we serve as Customer Zero for the company. It covers the tradeoffs we manage, the lifecycle patterns that hold up over time, and the signals we monitor to understand whether we’re reducing risk or quietly accumulating it.

We also share resources you can use to apply modern device management in your own enterprise.

“Every digital experience depends on the readiness of the devices our employees use every day,” says Brian Fielder, vice president of Microsoft Digital. “Organizations that treat device management as a strategic lifecycle capability rather than a series of operational tasks are better positioned to adapt to change, reduce risk, and take advantage of new innovations with confidence.”

Understanding device readiness and lifecycle

Effective device readiness must be sustained across the full device lifecycle, from planning and acquisition through operation, refresh, and retirement. In an enterprise environment, a device is considered ready only when we can:

• Identify it and confirm ownership
• Govern it through identity and policy
• Keep it secure and compliant over time
• Support and recover it when something goes wrong
• Remove it cleanly when its role ends

When these conditions work together, device readiness becomes an operating advantage. We can move employees onto approved devices faster, enforce security and access requirements more consistently, and make lifecycle decisions with better data and less guesswork. The result is a device estate that is manageable, trustworthy, and productive at enterprise scale.

The device lifecycle model

At Microsoft Digital, we use the device lifecycle as a control system for readiness. We connect decisions, standards, and signals across the full lifecycle, so we can manage readiness over time rather than just check on it at isolated points. Each stage reinforces the next, and any issues show up early enough for us to correct them before they spread.

The stages serve specific functions:

• Plan and standardize: Sets the device standards and guardrails that make the rest of the lifecycle workable at scale.
• Acquire: Brings devices in as approved enterprise assets that can be tracked and managed from the start.
• Onboard: Gets employees up and running quickly through automated setup and policy-driven enrollment.
• Operate: Ensures devices are secure, up-to-date, and dependable over time.
• Optimize: Uses telemetry to reduce friction and improve how the lifecycle performs.
• Refresh or reassign: Keeps devices useful longer by replacing or repurposing them before they become a problem.
• Retire: Removes devices cleanly so access is closed off, data is protected, and disposition is complete.

The device lifecycle is a durable operating model that we manage holistically. Weakness in any phase often appears after the original decision was made and far from the point where the issue began.

We describe each lifecycle stage using the following structure:

Readiness question

What must be true at this stage to enable readiness

What good looks like

Our outcome-oriented goals for the stage

Signals

How we identify drift or technical debt

Microsoft Digital operating practices

Systems and processes we use internally to make this stage durable and repeatable

Stakeholder lens

Who contributes or has expectations at this stage

Being Customer Zero

How we stress-test internally in Microsoft Digital and learns at scale

Chapter 1: Plan and standardize

In this stage, we define the standards, controls, and supported patterns that make the rest of the device lifecycle manageable. Good planning reduces downstream exceptions and gives later stages a more stable foundation.

Readiness question

Are our device standards enforceable in practice, and do they reduce downstream cost, risk, and fragmentation?

What good looks like

Clear, role-based device standards limit variance and make onboarding and support repeatable at scale. These standards are grounded in capabilities that our platforms and tools can enforce, not aspirational policy language.

Signals

Signals help us detect when a lifecycle stage is falling out of alignment with its intended outcomes, becoming harder to manage, or creating downstream cost and complexity. These signals include:

Exception rates that grow over time (more devices falling outside supported standards), which later shows up in higher support costs and weaker servicing consistency.

Policies that are documented but not enforced through device health and access controls, including modern management capabilities such as Intune compliance policies and Conditional Access. Some examples are minimum OS requirements, encryption standards, and Microsoft Defender health. Documented but unenforced controls create “paper compliance” instead of true operational compliance.

Device and OS coverage statements that become hard to verify. This could manifest as device counts, OS mix, and ownership mix becoming directional rather than telemetry-backed, which weakens credibility and decision making.

Microsoft Digital operating practices

These practices show how we design the operating model to make the target state durable and repeatable. They represent the baseline decisions we make around rollout control, visibility, and enforcement to help prevent drift before it emerges.

• Early partnership with chip providers such as Intel, AMD, Qualcomm, and NVIDIA enables upstream testing, validation, and feedback on next-generation hardware. As Customer Zero for the Windows product group, our team in Microsoft Digital co-develops and is an early adopter of the Copilot+ PC experience, so readiness, performance, and security are tested and proven before fleet-wide deployment.
• For Windows devices, readiness standards are anchored to enforceable hardware and security capabilities, including TPM 2.0, Secure Boot, Microsoft Pluton, Credential Guard, and Windows Hello for Business compatibility.
• Devices are sourced from approved OEM catalogs and built to order, then validated against supported firmware, BIOS or UEFI, driver configurations, and setup experience. This approach reduces downstream support, servicing risk and providing white-glove device preparation while supporting a consistent, secure out-of-box experience.
• Apple (macOS/iOS) readiness is anchored to managed enrollment, encryption (for example, FileVault on macOS), and phishing-resistant sign-in via Platform SSO and passkeys.
• Android readiness requires Android Enterprise Work Profile support, verified device integrity (not compromised), and minimum OS and security patch levels enforced via MDM posture and Conditional Access.

Stakeholder lens

The following stakeholder groups shape planning, depend on its outcomes, and can detect misalignment quickly when expectations drift:

Employees

Benefit from clear, role-appropriate device expectations.

Endpoint engineering

Defines standards and automation foundations.

Security

Partners on baseline posture and control requirements.

Procurement and finance teams

Influence catalog decisions and lifecycle cost models.

Being Customer Zero

Before broad deployment of new capabilities, enterprise endpoint teams and product groups align on an enterprise readiness contract that spans trust and safety, manageability, and recoverability. We validate identity-bound access and tenant trust boundaries early, so we don’t introduce unmanaged enterprise risk.

Chapter 2: Acquire

In this stage of device lifecycle management, we bring devices into the environment as known, trackable enterprise assets. The goal is to make sure every device enters the lifecycle with the identifiers, registrations, and sourcing controls needed for clean provisioning and management.

Readiness question

Are devices known, owned, and visible before employees need them?

What good looks like

Procurement and asset registration are predictable and integrated, ensuring devices enter the environment as known enterprise assets, already associated with inventory systems and ready for automated provisioning.

Signals

These signals show where breakdowns in sourcing, registration, or asset control can create problems later in the lifecycle.

Procurement lead times cause day-one onboarding delays when devices arrive before they are ready for provisioning.

Inventory and asset records drift from reality, causing organizations to lose a single source of truth for device status, ownership, and lifecycle stage. This can create gaps in offboarding, recovery, and audit evidence.

Devices reach employees before registration is complete, such as when Autopilot or Apple Business Manager registration isn’t done before delivery. This forces catch-up work and introduces exceptions.

Microsoft Digital operating practices

These practices show how we design the operating model to make the target state repeatable:

• Acquisition readiness and zero-touch deployment begin with an integrated sourcing and provisioning model. This model defines how we source and acquire devices globally, apply persona-based configuration, fulfill local language requirements, and preload the latest supported operating system and drivers.
• When devices are delivered, they arrive asset-tagged, bundled, and preregistered with Windows Autopilot. This enables a consistent, secure, hands-off setup experience from first power-on.
• Acquisition readiness is tied to asset registration and inventory accuracy. Corporate devices are registered at purchase, associated with enterprise asset identifiers, and tracked continuously from order through retirement.

Stakeholder lens

These groups influence acquisition decisions and depend on those decisions being accurate, timely, and supportable:

Procurement and finance

Own sourcing and logistics.

IT

Validates compatibility and enterprise readiness.

Security

Advises on supply chain and trust considerations.

Being Customer Zero

Our early adoption program accelerates learning while preserving governance. We operate under explicit guardrails, including security posture, data boundaries, and regulatory requirements, so speed doesn’t bypass enterprise controls.

Chapter 3: Onboard

In this stage, we turn a device into a usable, trusted work endpoint through automated setup, enrollment, and policy enforcement. A strong onboarding experience helps employees become productive more quickly without weakening identity or compliance controls.

Readiness question

Can employees be productive on day one, experiencing minimal friction without bypassing identity, policy, or compliance?

What good looks like

Onboarding is fast, predictable, and largely hands-off for IT while remaining identity-bound and policy-driven. Day-one productivity comes through repeatable automation rather than exception handling.

Signals

These signals tell us when onboarding is becoming inconsistent, support-heavy, or harder to scale cleanly:

“Time to productive” increases or varies significantly (the onboarding path is no longer repeatable at broad scale).

Enrollment Status Page (ESP) failures increase (setup blocks, app install delays, and policy install failures).

Enrollment-related support calls or tickets rise during onboarding windows, indicating that friction is shifting from automation to human support.

Post-onboarding surveys and helpdesk ticket analysis show declining satisfaction or repeated “same issue” patterns.

Bring-your-own-device (BYOD) enrollment confusion increases as employees are unclear on what’s managed, what data is collected, or what happens when access is revoked.

Microsoft Digital operating practices

These practices show how the operating model makes the target state repeatable:

• Devices are approved and certified before reaching employees. Corporate Windows and Apple devices are sourced from approved OEM catalogs and registered through Windows Autopilot or Apple Business Manager, then associated with user identities and asset systems.
• For Windows devices, Autopilot registration occurs via OEM or partner APIs whenever possible; manual hardware hash registration is reserved for exceptions. Assigned Autopilot profiles define Entra ID join behavior, Intune enrollment, Out‑of‑Box Experience configuration, required applications, and baseline policies.
• The Enrollment Status Page acts as a gate that can’t be bypassed. Devices cannot be used until required apps, updates, and policies are successfully installed. If setup fails, reset is blocked, and errors are captured for IT remediation.
• Apple Business Manager is used exclusively for corporate‑purchased Apple devices; personally owned Apple and Android devices follow Intune BYOD enrollment paths. Android devices enroll using the Android Work Profile mechanism; Google Zero Touch is not used in this environment.
• Before access to corporate resources is allowed, devices must meet certification requirements, including Intune enrollment, encryption (BitLocker or FileVault), supported OS versions, Defender for Endpoint health, and required hardware security capabilities. Conditional Access enforces these requirements at sign‑in.
• Virtual onboarding options such as Azure Virtual Desktop are used for contractors, regulated roles, or temporary fallback access.

Stakeholder lens

These groups own setup, experience the outcome directly, and rely on tight alignment for onboarding to work smoothly:

Employees

Expect a power-on-and-go experience.

IT

Owns provisioning automation and exceptions.

Identity and security teams

Validate trust and access enforcement.

Being Customer Zero

The readiness contract explicitly validates manageability, zero-touch onboarding readiness, and identity enforcement before capabilities advance beyond early internal cohorts.

Chapter 4: Operate

In this stage, we keep devices secure, current, and reliable through ongoing servicing and operational discipline. The aim is to maintain a stable experience over time while minimizing manual intervention and operational noise.

Readiness question

Can devices remain secure, reliable, and current over time without constant manual intervention, and can known vulnerabilities be remediated quickly without manual escalation?

What good looks like

Continuous servicing and support preserve productivity while minimizing operational noise and exposure windows.

Signals

These signals help us see when operations are getting noisier, less predictable, or more reactive than they should be:

Update compliance thresholds are missed, meaning more devices are at risk because of outdated patches or repeat failure patterns.

Rollbacks, pauses, or halted rollouts become frequent, which indicates that the ring and validation strategy isn’t catching issues early enough.

Helpdesk tickets trend upward for update failures or device remediation (operational noise is rising instead of staying quiet).

Firmware- or driver-related instability increases, which requires additional validation, staging, or rollback controls.

Zero-day response requires repeated emergency actions; this signals that baseline update hygiene isn’t consistently holding.

Microsoft Digital operating practices   

These practices show how we design the operating model to make the target state durable and repeatable:

• Windows Autopatch: Provides a single, integrated update management experience in Intune. It combines Windows Update for Business policy-based controls with automated, telemetry-driven deployment across staged rollout waves, including built-in issue detection, pause, and rollback capabilities.
• Windows Hotpatch: Helps reduce disruption by applying certain security updates without requiring a restart, which supports continuity for eligible devices.
• Intune Vulnerability Agent: Extends vulnerability visibility and supports coordinated remediation through device management workflows.
• Enterprise App Management: Gives us a structured way to manage application deployment, updates, and policy alignment across managed devices.
• Update Compliance: Via Azure Monitor, it provides insight into installation rates and failure patterns, triggering remediation workflows when thresholds are crossed. Firmware and driver updates are validated with OEM partners and staged using the same ring-based deployment model.
• Minimum OS requirements: Non-Windows devices must meet minimum operating system requirements, encryption standards, and endpoint protection requirements before they can access corporate resources. These are enforced by Intune compliance policies and Conditional Access.

Stakeholder lens

These groups keep the environment running smoothly and depend on that stability every day:

Employees

Experience quiet, predictable updates that minimize disruption and maintain productivity.

IT operations teams

Own reliability and remediation, so updates are delivered safely at scale.

Security teams

Use device compliance and update posture as critical signals for access control and risk reduction.

Being Customer Zero

We use a staged rollout approach to test new updates and features with progressively larger groups of users. This helps us identify issues early, validate performance and reliability at scale, and continuously improve quality before broad deployment across the company.

Chapter 5: Optimize

In this stage, we use telemetry and operational insight to improve how the device lifecycle performs. Optimization helps us reduce friction, close recurring gaps, and make better decisions about where to invest effort.

Readiness question

Are fleet health, compliance, and cost improving or merely visible?

What good looks like

Telemetry and automation inform decisions that decrease friction, eliminate compliance gaps, and improve lifecycle efficiency.

Signals

These signals show when optimization has stalled and the environment is absorbing effort without reducing friction or risk:

Known vulnerabilities remain open longer than expected, increasing exposure to risk.

Compliance rates stop improving from one release to the next, despite ongoing remediation efforts.

Routine issues continue to require manual intervention instead of being handled through automation.

Devices repeatedly cycle in and out of compliance, indicating deeper issues in the environment.

Operational reviews spend more time addressing recurring problems and less time improving the overall service.

Microsoft Digital operating practices

These practices help us improve the environment over time and reduce operational overhead. They focus on measuring results, standardizing management, and automating routine work where possible.

• Optimization investments are guided by metrics such as patch compliance, automation coverage, remediation success rates, and operational workload.
• We standardized Windows devices on Microsoft Entra ID join and retired older management models such as Workplace join, Hybrid Azure AD join, and Active Directory join. This reduced complexity, simplified policy enforcement, and created a more consistent management experience across devices.
• Windows Autopatch, Hotpatch, and automated remediation help us keep devices current while minimizing disruption for employees.
• Intune firmware, driver, and Enterprise App Management capabilities extend the same update and deployment discipline beyond the operating system to hardware components and third-party applications.
• Microsoft Security Copilot, Microsoft 365 Copilot, and Copilot in Power BI help our teams analyze Intune and Defender data more quickly, making it easier to identify issues and prioritize remediation efforts.

Stakeholder lens

Optimization in a cloud-native model depends on aligned ownership across engineering, security, and employee experience teams. Modern management gives us a standardized, policy-driven foundation.

Employees

Experience fewer disruptions and faster issue resolution.

Endpoint engineering and modern management teams

Drive standardization, policy enforcement, and continuous fleet health optimization.

Security and CISO partners

Rely on device compliance signals to enforce secure access with minimal manual intervention.

Product groups

Incorporate Customer Zero feedback from our team in Microsoft Digital to improve enterprise readiness.

Being Customer Zero

As Customer Zero for modern management, we validate optimization capabilities at enterprise scale and feeds insights directly to engineering. This helps ensure solutions are designed for real-world scenarios.

• Modern Management transformation (Entra ID–based) simplified management and closed Conditional Access gaps.
• Validation of Autopatch and Hotpatch improves update readiness and rollout quality before broad release.
• AI-powered investigations unified Defender and Intune signals to accelerate issue triage and remediation.

Chapter 6: Refresh or reassign

In this stage, we decide whether a device should continue in service, move to a new owner, or be replaced. When done with intention, refreshing and reassignment extend an asset’s value while reducing avoidable support issues and lowering security risk.

Readiness question

Are devices refreshed or reassigned before they become performance or security debt?

What good looks like

Condition-based refresh and reassignment maximize asset value while minimizing disruption.

Signals

These signals help us see when device reuse, replacement, or support timing is slipping out of a manageable rhythm:

Hardware health telemetry trends indicate looming failures, including battery wear, thermal events, and disk health degradation, which creates unplanned downtime risk.

Firmware or driver update readiness becomes inconsistent across models (this increases the cost of servicing and support).

Refresh timing becomes reactive (devices are replaced after repeated failures instead of during planned lifecycle windows).

Reassignment or reuse requires more manual work (this signals that reset and reprovision flows aren’t consistently repeatable).

Microsoft Digital operating practices

These practices show how we make device refresh and reassignment consistent, scalable, and repeatable. They aren’t reactive steps we take when aging devices, inventory gaps, or fulfillment delays become visible. They’re the standard processes, controls, and decision points we use to keep devices moving through their lifecycle efficiently and to prevent those issues from occurring in the first place.

• Windows lifecycle guardrails: Align firmware servicing and hardware support windows to a 48-month refresh baseline so devices remain within OEM-supported windows for security and firmware updates.
• Condition-based refresh signals: Battery wear, thermal events, disk health, and firmware servicing status are monitored through telemetry to trigger proactive refresh actions before devices become performance or security debt.
• Catalog discipline: Devices are sourced from the approved OEM catalog, with model selection tied to persona, lifecycle stage, and firmware support roadmap. This reduces drift between deployed inventory and supported hardware.
• Defined recovery workflow: Reassignment is supported through a documented recovery workflow where applicable. Previously owned corporate Windows devices are returned to the out-of-box experience using WinRE-based reset initiated locally or through Company Portal, enabling redeployment to new owners through Autopilot. Recovery USB is the documented fallback when WinRE can’t be used.
• Sustainability and cost outcomes: Where possible, devices are reassigned, repurposed, or returned through approved recycling channels. This extends asset value and supports our broader sustainability commitments.
• Structured exception handling: Devices that fall outside refresh windows because of supply, persona, or business constraints follow a documented exception path with a defined review cadence so exceptions don’t become the norm.

Stakeholder lens

These groups help determine whether devices should be refreshed, reassigned, repaired, or retired:

Employees

Need reliable devices that support their work without repeated failure or disruption.

Endpoint engineering and support teams

Use telemetry and recovery workflows to guide refresh and reassignment decisions.

Procurement, finance, and sustainability teams

Balance device value, lifecycle cost, reuse, and responsible disposition.

Being Customer Zero

Our team in Microsoft Digital validates refresh and reassignment workflows at scale across device models, OEMs, and silicon partners before they reach employees. By partnering early with Windows product group, silicon partners, and OEM partners, we test Autopilot re-enrollment, WinRE-based recovery, and Company Portal reset flows in real conditions. We then turn lifecycle telemetry and friction points into direct product feedback as part of our Customer Zero commitment.

Chapter 7: Retire

In this stage, we close the lifecycle cleanly by removing devices from service in a controlled and auditable way. Retirement helps ensure that access is revoked, data is protected, and disposition is complete.

Readiness question

Can devices exit cleanly without leaving behind data, access, or audit gaps?

What good looks like

Offboarding is policy-driven, auditable, and integrated with identity, asset, and sustainability workflows.

Signals

These signals show where offboarding is leaving loose ends that can create exposure, confusion, or audit gaps later:

Orphaned devices appear (devices aren’t tied to an active person or remain enrolled after a lifecycle trigger).

Time to offboard grows (slow decommissioning creates prolonged access and data risk).

Wipe verification and audit artifacts are incomplete (this includes missing wipe confirmation logs, disposition certificates, or chain-of-custody records).

Devices remain enabled in Entra ID or continue to pass access checks after they should be decommissioned (these are access revocation gaps).

People repurpose devices informally, such as loaners or secondary devices, without clarity on what decommissioning means for audit and compliance versus reassignment.

Microsoft Digital operating practices

Offboarding triggers include employee exit, end of warranty, hardware health degradation, or compliance failure. These triggers launch automated workflows using Power Automate and ServiceNow, revoke access through Microsoft Entra ID and Conditional Access, and wipe devices through Intune or Configuration Manager. Data sanitization aligns with NIST 800-88 guidelines, and chain-of-custody controls support secure disposition.

Stakeholder lens

These groups help ensure retirement is controlled, auditable, and complete:

Employees and managers

Return devices and confirm lifecycle events that trigger offboarding.

IT operations and asset teams

Coordinate wipe, recovery, inventory updates, and disposition records.

Security, compliance, and sustainability teams

Validate access removal, data sanitization, chain of custody, and responsible disposition.

Being Customer Zero

Our team in Microsoft Digital validates retirement workflows at scale, including automated offboarding, access revocation, NIST 800-88 sanitization, and chain-of-custody controls across devices. By partnering with Microsoft Entra ID, Windows, and Intune teams, we surface real-world gaps such as orphaned devices, delayed wipes, and residual access. We then translate those gaps into product improvements that strengthen the retirement experience for customers and help keep our own audit and compliance posture durable.

Conclusion

Device readiness is not a one-time milestone. It is a lifecycle discipline that connects planning, sourcing, onboarding, operations, optimization, refresh, and retirement. At Microsoft Digital, we use that lifecycle to keep devices secure, employees productive, and operational decisions grounded in data.

“Device readiness is ultimately about enabling people to do their best work wherever and however they choose to work. By treating the device lifecycle as a strategic capability, we’ve transformed this function from an operational necessity into a source of innovation, resilience, and future growth across our organization.”

Senthil Selveraj, principal group product manager, Microsoft Digital

When every stage has clear standards, measurable signals, and repeatable mechanisms, the device estate becomes easier to manage and safer to scale. That helps us reduce exceptions, improve employee experience, and strengthen enterprise security without relying on manual effort as the default path.

“Device readiness is ultimately about enabling people to do their best work wherever and however they choose to work,” says Senthil Selveraj, a principal group product manager in Microsoft Digital. “By treating the device lifecycle as a strategic capability, we’ve transformed this function from an operational necessity into a source of innovation, resilience, and future growth across our organization.”

The post How we deploy and manage enterprise devices at Microsoft Digital appeared first on Inside Track.

That was the guiding mantra behind an ambitious cross-company effort involving our team in Microsoft Digital—the company’s IT organization—and a number of our product teams. The effort, internally referred to as the Securing AI Agents initiative, brought together teams from Microsoft Digital, Windows, Entra, Intune, Defender, Purview, and Microsoft Security to validate secure AI agent scenarios inside Microsoft’s corporate tenant.

Together, we set out to prove that AI agents could operate safely inside a real enterprise environment, not just in a controlled demonstration.

“Securing AI in the enterprise at pace requires an integrated, full-stack approach. By validating these capabilities together at enterprise scale, we’re generating the real-world learning to strengthen Microsoft’s products and give customers a trusted blueprint for secure AI adoption.”

Ragini Singh, partner group engineering manager, Microsoft Digital

As part of our role as the company’s Customer Zero, this work was recently showcased by Samantha Song and Scott Hanselman at the Microsoft Build 2026 conference.

“Securing AI in the enterprise at pace requires an integrated, full-stack approach,” says Ragini Singh, a partner group engineering manager in Microsoft Digital. “By validating these capabilities together at enterprise scale, we’re generating the real-world learning to strengthen Microsoft’s products and give customers a trusted blueprint for secure AI adoption. Looking ahead, our vision is to make this integrated security foundation the standard for every enterprise, so organizations can scale autonomous agents with speed, confidence, and trust.”

The Secure AI Agents initiative was the result of an all-hands-on-deck project behind the scenes here at Microsoft: Months of testing, coordination, validation, and refinement that transformed an emerging concept into a governable enterprise pattern.

“All of these teams came together and not only enabled the environment in our IT tenant but also ensured that all the right policies were deployed to make it so that these agents can run safely. That meant not bypassing any of the security parameters that we’ve already deployed.”

Shyam Sunder Gogi, technical program manager, Microsoft Digital

Shyam Sunder Gogi, a technical program manager in Microsoft Digital, served as the organizer of the effort, which initially began with a two-week sprint to get ready for Microsoft Build 2026. The project eventually involved more than 70 stakeholders representing different product and business groups.

“All of these teams came together and not only enabled the environment in our IT tenant but also ensured that all the right policies were deployed to make it so that these agents can run safely,” Gogi says. “That meant not bypassing any of the security parameters that we’ve already deployed.”

Testing in real-world scenarios

Rather than validating solutions in an isolated sandbox, we ran a pilot inside Microsoft Digital, standing up a dedicated Windows 365 Cloud PC environment for roughly 100 internal users.

Pilot participants put the solution through its paces across common developer scenarios. These included:

• Windows OS images with Copilot CLI and OpenClaw pre-installed
• Windows 365 Cloud PC provisioning
• Entra Agent IDs to distinguish human and agent identities
• Defender runtime protection and Purview data loss prevention policies
• Intune device and agent configuration policies
• Microsoft Entra Global Secure Access (GSA) network security controls at runtime

Our goal was to pressure-test a full stack of security guardrails, and to do it the way an actual customer would: with real users and real workloads.

“Customer Zero only works if you’re willing to be the first to hit the rough edges,” says Tom McCleery, a principal group cloud network engineering manager on the Microsoft Infrastructure, Network and Tenant (MINT) team here in Microsoft Digital. “We took the agent scenarios into a live tenant with real users, found the issues product teams couldn’t have surfaced in a lab, and fed every one of them back to the team to address before this ever reached broader enterprise readiness.”

The decision to use Windows 365 Cloud PCs in the pilot proved important.

“We want these device agents to run on our employees’ primary machines, and when necessary, to run on a secondary machine that can be easily isolated and reset if needed,” says Dave Rodriguez, a principal product manager for the Endpoint Experience (EE) team in Microsoft Digital. “That’s why we chose to go with Windows 365 Cloud PCs as a corporate-bound, non-primary environment, where we could have our end users work with those machines as they would with any other device.”

The approach created a safe environment for experimentation while giving teams realistic deployment conditions.

“With Windows 365, there’s no real impact to the devices that we’re using,” says Harshitha Digumarthi, a senior product manager on the EE team. “I really love how we leveraged Windows 365 for piloting this, iterating each time there was a change.”

Digumarthi and her team helped to establish and validate all administrative controls and policies, confirm that they function as expected, and execute a phased rollout strategy—starting with pilots and expanding incrementally while proactively monitoring for risks and user impact.

Identity, data, and network controls under load

Much of the runtime security work fell to our Microsoft Digital team, which validated how the controls behaved once agents were actually operating. A foundational aspect was telling humans and agents apart, so that rules and governance can be more clearly defined based on who is overseeing a process.

“Entra Agent IDs let us give an agent its own distinct identity, instead of having it borrow a person’s,” says Joshua Green, principal software engineering manager on the Microsoft Digital team. “Once you can cleanly separate human and agent identities, everything downstream—access decisions, auditing, runtime protection—gets dramatically more trustworthy.”

On the protection and data-governance side, MINT exercised Defender and Purview against agent activity.

“We validated Defender runtime protection and Purview data loss prevention against live agent behavior,” says Diego Baccino, a principal software engineering manager on the MINT team. “It’s one thing to write a DLP policy; it’s another to confirm that it actually catches what an autonomous agent might try to move. That testing is exactly the kind of value that Customer Zero adds.”

Network-layer controls rounded out the stack.

“Entra Agent IDs let us give an agent its own distinct identity, instead of having it borrow a person’s. Once you can cleanly separate human and agent identities, everything downstream—access decisions, auditing, runtime protection—gets dramatically more trustworthy.”

Pradeep Kunjunny, principal PM manager, Microsoft Digital

This was the advantage of using Global Secure Access, showing that the effort worked with traffic loads generated by a real agent.

“Entra Agent IDs let us give an agent its own distinct identity, instead of having it borrow a person’s,” says Pradeep Kunjunny, a principal PM manager in Microsoft Digital. “Once you can cleanly separate human and agent identities, everything downstream—access decisions, auditing, runtime protection—gets dramatically more trustworthy.”

From pilot to platform

Across the initiative, Microsoft Digital drove coordination and execution across multiple organizations.

“Our close collaboration with Microsoft Digital demonstrates the power of validating security capabilities for AI agents in one of the world’s largest and most complex enterprise environments. The insights we gain from real users and workloads help us strengthen our products and give customers greater confidence as they adopt AI agents securely.”

Aakarsh Nair, vice president of engineering, Microsoft Security

Pilot onboarding, validation of Intune-managed control rollouts, and rapid issue-triage loops improved decision confidence before it was demonstrated at Build, and it shaped the product to prepare it for broader enterprise use.

“Our close collaboration with Microsoft Digital demonstrates the power of validating security capabilities for AI agents in one of the world’s largest and most complex enterprise environments,” says Aakarsh Nair, vice president of engineering in Microsoft Security. “The insights we gain from real users and workloads help us strengthen our products and give customers greater confidence as they adopt AI agents securely.”

The result is a validated blueprint—endpoint, identity, data, and network controls working together—that our customers can now look to as they bring AI agents to their own tenants.

“The winners in enterprise AI won’t just be the teams with the best model experience. They’ll be the teams that make AI operationally trustworthy within the enterprise.”

Tunde Makinde, senior service engineer, Microsoft Digital

It was an initiative that was all about proving that secure AI agent scenarios could work in a real enterprise environment, not just in a demo or a lab setup.

“The winners in enterprise AI won’t just be the teams with the best model experience,” says Tunde Makinde, a senior service engineer for tenant integration and management engineering in Microsoft Digital. “They’ll be the teams that make AI operationally trustworthy within the enterprise.”

Our Secure AI Agents initiative is reinforcing a lesson we’ve learned repeatedly as Customer Zero for the company: Successfully deploying AI in the enterprise isn’t just about delivering innovative capabilities, it’s about ensuring that identity, endpoint, network, runtime, and data protections work together as a cohesive system, enabling employees to use new technologies with confidence while maintaining the governance and security standards that organizations expect.

“By validating these capabilities together at enterprise scale, we’re generating real-world learning to strengthen our products and give customers a trusted blueprint for secure AI adoption.”

Ragini Singh, partner group engineering manager, Microsoft Digital

By bringing together teams from across Microsoft and validating these capabilities in a live enterprise environment, we were able to test how AI agents perform under real-world conditions. The result was more than a successful Build demonstration. It was a practical blueprint that informs how we build our products and provides valuable guidance for companies preparing to adopt agents at scale.

“Securing AI in the enterprise at pace requires an integrated, full-stack approach,” Singh says. “That’s why our team in Microsoft Digital brought together Microsoft Agent 365, Windows 365, Intune, Entra Agent ID and Global Secure Access, Defender, and Purview to secure our agents.”

Working in concert across endpoint, identity, network, runtime, and data, our partnership helped establish the layered security model needed to secure our AI agents.

“By validating these capabilities together at enterprise scale, we’re generating real-world learning to strengthen our products and give customers a trusted blueprint for secure AI adoption,” she says.

Looking ahead, our vision is to make this integrated security foundation the standard for every enterprise, so organizations can scale autonomous agents with speed, confidence, and trust.

The post Securing AI agents in the enterprise: Learnings from our journey at Microsoft appeared first on Inside Track.

Every one of those devices relies on Secure Boot, a Windows security capability that verifies firmware, boot loaders, and operating system components before startup. This system helps ensure all our Windows devices run only trusted software and protects us against threats that target the boot process.

When three Microsoft-issued Secure Boot certificates approached expiration in 2026, our team in Microsoft Digital, the company’s IT organization, knew we needed to take action early and get ahead of the update. By partnering with the Microsoft Office of the CISO and several of our product teams, we developed an approach that ensured secure-by-default devices from the firmware up.

Updating the foundation of device trust

Secure Boot sits at the foundation of Windows security. Without updated certificates, devices would lose the ability to receive future Secure Boot protections and other boot-level security improvements.

“We manage a diverse fleet of devices and usage scenarios, so we needed an approach that could scale safely, provide visibility into our progress, and maintain confidence in device security.”

Luis Quintana, principal engineering group manager, Endpoint Security

To maintain protection, we needed to replace three legacy certificates with four new ones across a diverse device fleet. Replacing the certificates was straightforward. The real work was validating the update across thousands of device models and deployment scenarios.

We started early so we could test, validate, and gradually deploy the updates before the certificate expiration dates arrived. That approach helped us strengthen the security posture of our devices while minimizing disruption to employees and business-critical systems.

“Updating hundreds of thousands of devices without disrupting people and business operations is no small task,” says Luis Quintana, principal engineering group manager for Endpoint Security. “We manage a diverse fleet of devices and usage scenarios, so we needed an approach that could scale safely, provide visibility into our progress, and maintain confidence in device security.”

Leading the update across a complex device estate

We first began this work in 2024 by partnering with the Windows Servicing and Delivery team, which helped us identify device models the certificate renewal might affect. We tested those models end to end in our Client Test Lab, then deployed the update to a pilot group of around 35,000 devices using a controlled firmware release (CFR). That pilot achieved a 95% success rate, which gave us the confidence to scale up.

“Intune was the glue that brought the process together, turning a collection of settings and instructions into something we could orchestrate. It helped us create a repeatable playbook that covered everything from reporting and targeting to rollout.”

Kubilay Dagdelen, senior service engineer, Microsoft Intune

In February 2026, we kicked off the broader effort across our entire Windows 11 device ecosystem. Reporting and telemetry formed our essential starting point.

Microsoft Digital partnered with the Windows Autopatch, Intune, and Microsoft Defender for Endpoint teams to identify which devices already included the latest certificates because they were released after 2025, which devices needed the update, and which failed. In support of these efforts, the Autopatch team built fleet-wide reporting of Secure Boot status directly into Intune, turning raw telemetry into a live compliance dashboard.

“Intune was the glue that brought the process together, turning a collection of settings and instructions into something we could orchestrate,” says Kubilay Dagdelen, a senior service engineer on the Microsoft Intune team. “It helped us create a repeatable playbook that covered everything from reporting and targeting to rollout.”

A ringed approach across a range of devices

We started small, using telemetry signals to identify device cohorts based on their risk of failure. Starting from the simplest devices to update, we gradually scaled across models that carried more complexity, keeping backups and loaner machines ready to support global operations in case of disruption. After just 70 days, we had achieved 86% compliance across all our devices.

“This has been an opportunity to strengthen our security foundation. It’s about going from reactive security to a secure-by-default baseline aligned with Zero Trust principles.”

Pandurang Savagur, senior product manager, Microsoft Digital

But we don’t just maintain employee devices. Our hardware estate spans meeting rooms, secure admin workstations, digital signage, and executive devices. These different device types demanded different Secure Boot approaches.

To tackle this challenge we established a virtual team, with members responsible for each of these surfaces holding weekly syncs and leadership updates. For example, our 15,000 meeting room devices run a custom Windows 11 image, so we partnered with OEMs to release firmware for them.

Meanwhile, cloud PCs on Azure infrastructure needed scheduled reboots to update, so we let employees choose when to restart. For our server cohort, where telemetry gaps made progress hard, Microsoft Defender for Endpoint delivered the independent visibility we needed.

“This has been an opportunity to strengthen our security foundation,” says Pandurang Savagur, a senior product manager on the Device Lifecycle team in Microsoft Digital. “It’s about going from reactive security to a secure-by-default baseline aligned with Zero Trust principles.”

Our Customer Zero experience: Expertise and process pathfinding

Our role as Customer Zero shaped how we approached this process. As both the creators and users of Microsoft technology, we have direct access to product teams as well as intimate knowledge of our tools’ capabilities.

“Technology and culture matter equally here, and our Microsoft culture means we know what’s coming and can act proactively through direct access to our engineering groups.”

Yulia Evgrafova, principal security service engineer, Office of the CISO

Intune served as our execution engine, orchestrating policies and remediation scripts across more than 90% of our devices with precision. Autopatch and Defender added speed through visibility.

Thanks to the lessons we learned throughout our update journey, we’re in the process of incorporating capabilities we developed internally into each solution for public release. We’ve also established steps that can help you manage your own Secure Boot certificate updates.

“Technology and culture matter equally here, and our Microsoft culture means we know what’s coming and can act proactively through direct access to our engineering groups,” says Yulia Evgrafova, a principal security service engineer for our Office of the CISO. “On the technology side, we have the expertise to experiment and the privilege of reaching engineering teams directly.”

Secure by default and ready for what’s next

Thanks to thorough telemetry and a measured approach to rolling out the update, we’ve now reached 97% compliance globally, all while keeping our failure rate under one percent and our support burden low. Our devices now validate trusted firmware and boot components by default, keeping the list of trusted components current and closing gaps that attackers could exploit at startup.

This work continues as we collect logs on devices that need attention and remediate the stragglers, including meeting rooms and virtual machines. That long tail is the hard part, but it’s a natural component of any effort at this scale.

What we built here reaches well beyond one certificate update. Telemetry gave us the visibility to protect devices without disrupting people, and that aspect of this rollout will guide get compliant and stay compliant in the future.

“This effort serves as a playbook for many different initiatives that we’ll take on in the future,” Quintana says. “One of the biggest lessons is how we can balance experience and protection between Microsoft Digital and our security teams.”

The post Keeping the enterprise secure by default: Secure Boot certificate updates at Microsoft appeared first on Inside Track.

This article presents our approach to cybersecurity risk management, detailing the internal governance structures, lifecycle methodologies, regulatory compliance processes, and organizational practices that collectively promote transparency and accountability. This approach is built on two foundational components: a structured risk management lifecycle and a governance model that integrates cybersecurity risk into enterprise-level decision making.

Governance as the foundation

Microsoft’s cybersecurity risk management program is fundamentally structured around robust governance mechanisms. Central to this framework is the Cybersecurity Governance Council, a cross-functional body composed of the Chief Information Security Officer (CISO), Deputy CISOs (DCISOs), and representatives from legal and regulatory affairs. This council convenes twice weekly to evaluate emerging risks, validate mitigation plans, and ensure alignment with enterprise priorities.

The governance model is designed to facilitate bidirectional communication of risk intelligence. Information flows upward from engineering and operational domains to executive leadership, and downward from strategic oversight to operational execution. This exchange is essential for maintaining situational awareness and ensuring that risk mitigation efforts are both evidence-based and scalable.

At the operational level, DCISOs are accountable for reviewing, prioritizing, mitigating, and accepting risks within their domains. This domain-aligned ownership model ensures that accountability for cybersecurity risk is clearly defined and directly connected to enterprise decision making.

Once risks are identified, they are reviewed on a recurring basis and aggregated to inform enterprise-level prioritization. Risk acceptance decisions are tiered based on residual risk levels and aligned with Microsoft’s defined risk appetite. They are then governed and monitored to ensure consistency and appropriate oversight.

Foundational elements

Listening systems

• Internal and external audits
• Current and pending regulation
• Incidents and media
• Industry groups

Methodology

• Risk management framework
• Risk rating criteria
• Risk universe

Tools

• Power BI
• Risk portfolio and accountability matrix
• Risk assessments
• NIST cybersecurity assessments

Risk domains

• Cybersecurity
• Quality and availability
• Business resilience
• Corruption
• Digital safety and service misuse

• Product safety
• Sustainability
• Global trade
• Antitrust and regulation
• Talent management

• Data privacy
• Supply chain
• Financial
• Facility security and people safety

Operational risk

• Search, advertising, and news
• Artificial intelligence
• Cloud and AI
• Commercial business
• Consumer business

• Security
• Experience + Devices
• Customer and partner solutions
• Gaming
• LinkedIn

• Corporate, External, & Legal Affairs (CELA)
• Finance
• Human resources
• Business development and corporate strategy
• Marketing

Enterprise risk

• Identify, assess, and prioritize risk to strategy

• Senior leadership accountability and mitigation quality

• Enable board risk governance

Microsoft’s security standards are published on an annual basis, establishing explicit requirements for risk entry, scoring, and mitigation. Adherence to these standards is mandatory for all teams, ensuring uniformity and accountability across the organization. The standards are subject to periodic revision in response to evolving threats, regulatory developments, and historical incident analysis.

The CISO GRC team synthesizes risk intelligence into a semi-annual enterprise risk management (ERM) report. The report is disseminated to senior leadership and the audit committee, elevating cybersecurity risk management from operational domains to the highest levels of organizational oversight.

Microsoft also defines and tracks key risk management metrics to measure and evaluate the effectiveness of its cybersecurity risk management program, providing visibility into risk posture over time and enabling informed decision making as part of governance and reporting processes.

A lifecycle approach to risk management

Microsoft’s risk management lifecycle is organized into four principal stages: identification, assessment, mitigation and remediation, and prevention and monitoring. Each stage is designed to ensure that risks are logged, actively managed, tracked, and validated.

Risk identification draws on a range of inputs, including threat intelligence, penetration testing, post-incident reviews, security research reports, red team exercises, and internal assessments. Risks are also surfaced through self-identification by teams, findings from defense operations, and structured self-assessments, such as the annual NIST Cybersecurity Framework (CSF) maturity review. The process is designed to be inclusive, allowing any employee or vendor with appropriate access to submit risks into a centralized system. This multifaceted approach aims to provide a comprehensive view of the threat landscape.

Upon identification, risks are entered into a centralized risk register, which provides early visibility and facilitates prompt action. The system is designed to be inclusive, permitting any employee or vendor with corporate access to submit risks. This democratized process reflects Microsoft’s commitment to broad-based risk identification across the organization.

Risk assessment is conducted by specialized teams employing structured methodologies, including impact and likelihood scoring, root cause analysis, and contextual evaluation informed by both internal signals and external intelligence. Assessment methodologies align with enterprise risk management practices and incorporate factors such as impact, likelihood, and management action and control opportunities to determine overall risk prioritization. Curators, who are Microsoft domain experts with risk management training, triage and assign risks to the appropriate DCISO area, thereby ensuring consistency and objectivity across all domains.

Risk mitigation and remediation strategies are tailored to the specific characteristics of each risk. Mitigation efforts may be prioritized and driven at an enterprise level through initiatives such as the Secure Future Initiative (SFI), or managed within specific organizational domains depending on scope and impact. These may involve deploying new controls, process adjustments, or implementation of technological solutions. Each risk is assigned an owner who is accountable for executing the mitigation plan and validating its effectiveness. Progress is monitored through workflow systems, and validation steps are employed to confirm the sustained efficacy of mitigations. Following mitigation, outcomes may inform updates to Microsoft security standards to strengthen systemic controls and prevent recurrence.

Prevention and monitoring constitute ongoing activities. Insights derived from mitigation efforts are also used to inform improvements delivered to customers, including secure-by-default configurations, product controls, and published guidance. Microsoft utilizes regression prevention techniques, continuous monitoring tools, and assurance systems to ensure the durability of mitigations over time. Insights derived from these activities are reintegrated into the identification process, thereby establishing a continuous improvement loop that is essential for maintaining resilience in a dynamic threat environment.

The risk register: Centralized oversight

The cybersecurity risk register functions as the central repository for Microsoft’s risk management program.

The workflow for risk management within the register encompasses seven defined stages: submission, triage, response, confirmation, information sharing, mitigation, and archiving. Each stage is governed by explicit service-level agreements to ensure accountability.

Risks are required to be triaged and scored within a specific timeframe following submission, and mitigation plans must be developed within a defined period after prioritization. Risk owners are required to provide regular, ongoing updates on the process of mitigation activities.

To support this workflow, roles within the risk register are clearly delineated:

• Risk Submitter: Responsible for providing comprehensive descriptions and supporting documentation for identified risks
• Risk Curator: Charged with validating, prioritizing, and assigning risks to appropriate domains
• Risk Owner: Accountable for implementing and monitoring mitigation plans
• Risk Viewer: Individuals such as auditors and senior leaders who access risk data for oversight and compliance purposes

In addition to these roles, DCISOs provide domain-level oversight and accountability for risks, including prioritization, acceptance, and escalation to enterprise governance structures.

Risk Submitter

The Risk Submitter is an individual, FTE or vendor who enters a new or existing risk into the Risk Register. Anyone with corp access can submit a risk, including Microsoft security experts. Responsible for submitting a clear, detailed, and understandable title, description, and supporting information for a risk.

Risk Curator

Delegated to take action by their DCISO, these are engineers, architects or analysts with respective domain knowledge and context who are responsible for triaging and prioritizing submitted security risks, ensuring the right DCISO area ownership alignment, identifying ownership, and tracking remediation.

Risk owner

The Risk Owner is an FTE, typically in a DCISO’s scope, that is responsible for updating mitigation status of a prioritized risk. This accountability continues until all mitigations are complete and the risk is deprioritized or archived.

Risk Viewer

The Risk Viewer is an FTE who requires read-only access to risk data to fulfill a business or compliance obligation. Where possible, their access is limited to PBI reports instead of direct access to the Risk Register itself.

Risks are reviewed on a quarterly basis, and prioritized lists are communicated to leadership to inform strategic decision making. The centralized risk register enables prioritized risks to be surfaced and reported to the CISO function and Enterprise Risk Management (ERM), supporting enterprise-level visibility and oversight. These prioritized risks inform the Secure Future Initiative (SFI), which drives systemic change across Microsoft.

Regulatory compliance integration

Microsoft’s cybersecurity risk management program is aligned with global regulatory frameworks, including ISO 27001, NIST SP 800-53, and the NIST Cybersecurity Framework, and is continuously updated to incorporate emerging requirements such as DORA and NIS2. These regulatory baselines inform both control implementation and risk evaluation, ensuring alignment between compliance requirements and operational risk management activities.

DCISOs are responsible for regulatory implementation and compliance within their respective domains. This encompasses oversight of regulated sectors such as healthcare, legal, and government, as well as emerging domains including artificial intelligence safety and privacy. The Cybersecurity Governance Council conducts regular reviews of regulatory risks and ensures that mitigation strategies are aligned with statutory and legal obligations.

ERM reporting integrates cybersecurity risks alongside financial and operational risks, thereby ensuring that regulatory compliance is embedded across the organization’s overall broader risk posture. This integrated approach enables Microsoft to respond expeditiously to regulatory changes and maintain trust with customers, partners, and regulatory authorities.

What makes Microsoft’s approach unique

The scale and complexity of Microsoft necessitate a risk management methodology that is both rigorous and adaptable. Several practices distinguish Microsoft’s program from industry counterparts.

The Secure Future Initiative (SFI) establishes a structured mechanism for driving systemic change, prioritizing critical risks and aligning mitigation efforts across engineering, operations, and executive leadership. While not all risks are represented within SFI, the initiative functions as a strategic accelerator, publicly articulating the prioritized risks and corresponding mitigation efforts that drive enterprise-wide improvements.

The culture of risk awareness is embedded throughout the organization. Risk identification is actively encouraged, and submissions are evaluated irrespective of origin, reflecting a commitment to democratized and proactive risk reporting. Internally, Microsoft advocates for a culture that celebrates the identification of risks and enables proactive reporting.

The governance cadence is highly disciplined; the Cybersecurity Governance Council convenes twice weekly, and DCISOs conduct reviews and confirm top risks every 90 days. These structured intervals ensure that risk management remains proactive, with clear accountability and continuous oversight.

The integration of operational and enterprise risk is seamless. The CISO GRC team synthesizes risk intelligence from across the organization and presents it in a unified ERM report, ensuring that cybersecurity risks are incorporated into strategic decision making, rather than isolated within technical silos.

Finally, Microsoft’s control ecosystem reinforces the durability of risk mitigation. Initiatives like the Secure Development Lifecycle (SDL), exception governance processes, and SFI collectively ensure that mitigations are implemented and sustained over time.

A blueprint for security leadership

Microsoft’s cybersecurity risk management program is a model of maturity, scalability, and transparency. The program integrates structured governance, rigorous processes controls, and a culture of accountability to ensure that risks are systematically identified, mitigated, and subject to continuous monitoring and improvement. For cybersecurity leaders seeking to understand risk management at scale, Microsoft offers a compelling blueprint: a proactive, integrated, and transparent framework that combines structured governance, rigorous process controls, and a culture of accountability.

Ultimately, cybersecurity risk management is not solely dependent on technical controls and frameworks; it is fundamentally about empowering individuals, building trust across teams, and connecting operational rigor with strategic clarity. If you are developing or refining your program, prioritize both structural and cultural elements, and build resilient processes around engaged teams. Security leadership presents significant challenges, but with the appropriate structure, culture, and rhythm, it can drive transformative outcomes.

The post How we approach cybersecurity risk management at Microsoft appeared first on Inside Track.

Our Global Collection team in the Microsoft Treasury division makes sure payments are seamlessly executed in our fast-moving global enterprise environment. However, our case managers were often losing valuable time figuring out things like who the right contact was for a given customer, which issues were likely to be challenged by a customer, and where an exception should be routed next. This information was spread across systems or buried in handoffs.

To solve these challenges, our team built a human-led, AI agent-assisted support system to reduce preparation time and streamline their processes.

“Building the AI assistance wasn’t the hard part,” says Kathy Brustad, a director in the Global Treasury and Financial Services division at Microsoft. “The hard part was reimagining the collection experience with AI front and center, and bringing the underlying infrastructure up to speed to get it there.”

In this post, we explain how we did it so you can learn from our experience.

“We have over 1,000 collectors around the world who perform collections for Microsoft. They had multiple systems they had to go to in order to find out things like the totality of the customer’s invoice and what conversations a different team had with the customer. The information was fragmented.”

Kathy Brustad, director, Global Treasury and Financial Services

Stitching together information across systems

Our AI agent is focused on helping our case managers prioritize high-value work by:

• Predicting late payments and possible customer disputes
• Summarizing customer case interactions for use by case managers
• Routing customer emails to the right collections manager faster and with greater precision Automatically matching payments to invoices
• Automatically responding to customer inquiries

“We have over 1,000 collectors around the world who perform collections for Microsoft,” Brustad says. “They had multiple systems they had to go to in order to find out things like the totality of the customer’s invoice and what conversations a different team had with the customer. All of this information was fragmented. We didn’t have a single view of how much a customer owed us.”

We started by consolidating these dispersed tools and systems into an SAP and Microsoft Dynamics 365 environment, creating a single source of truth for all relevant customer, invoice, and payment data.

On that foundation, we layered on Microsoft’s IQ intelligence platform to infuse semantic understanding and business context. That standardized our workflows by simplifying templates and worklists to reduce complexity and put consistent global practices into place. Routine communications became fully automated.

We then applied AI to improve payment matching accuracy from 40% to 90%, generate customer response drafts, and intelligently route cases to reduce time-consuming back‑and‑forth.

Copilot assistance was embedded directly into the daily workflow of our case managers to reduce administrative load by providing inline knowledge suggestions, summarizing calls, and automatically drafting replies. With these standardized automated workflows, we could apply 98% of payments within 48 hours.

“In a nutshell, this is the collection story: We have various agents and models deployed to assist our human agents with all the activities they have to do, saving hundreds of thousands of hours that we spent on manually tracking things before.”

Kathy Brustad, director, Global Treasury and Financial Services

Moving faster on ‘act ready’ work

Deploying the agent was only the starting point. The harder work was helping our collection team change established ways of working. Brustad described the shift as learning to “run it in a different way,” moving from manual, fragmented preparation toward workflows where prioritization, context gathering, and routing were increasingly supported within the system.

To make that shift possible, the team introduced a change management work stream program and role-based training focused on real, day-to-day scenarios alongside the rollout. By anchoring the work in clear business pain points and showing tangible improvements, our team saw how the new approach made their work easier. Each morning, the agent prioritized each case manager’s workload according to urgency and past client behavior so case managers could immediately focus on the accounts that were the most pressing.

We reduced repetitive communications using automatically drafted responses and automated statements.

“In a nutshell, this is the collection story: We have various agents and models deployed to assist our human agents with all the activities they have to do, saving hundreds of thousands of hours that we spent on manually tracking things before,” Brustad says.

After deploying this system to our case managers, we saw measurable improvements in both productivity and speed, including:

• Hundreds of thousands of hours unlocked annually in order to do more human-led high-value work rather than routine administrative tasks
• 40% reduction in call preparation time
• 2X growth in automatic cash applications
• 2.5X acceleration of customer inquiry resolution time

Operationally, the team also saw up to 60% reduction in inquiry handling time through inline suggestions, summarized calls, and automatically drafted replies. To ensure these improvements were real and repeatable, we emphasized observability in our evaluation approach. Our team tracked dollars collected through collections and hours worked to create productivity metrics.

Data, trust, and good governance

When introducing AI systems or agents into finance workflows, leaders often ask two questions:

1. Can we trust the outputs?
2. Can we govern the process?

“The biggest takeaway is to know your own process very, very well. You need to understand where all the bottlenecks and pain points are. Start from there to design the new agent-enabled process instead of saying, ‘I’m going to just inject the agent into my existing process.’”

Kathy Brustad, director, Global Treasury and Financial Services

For us, trust came from getting the basics right in the form of right-sizing our enterprise data, standardizing our workflows, and establishing clear ownership for each part of the work. When we tested early and included frontline users throughout the process, outcomes improved.

“The biggest takeaway is to know your own process very, very well,” Brustad says. “You need to understand where all the bottlenecks and pain points are. Start from there to design the new agent-enabled process instead of saying, ‘I’m going to just inject the agent into my existing process.’”

Embed custom agent assistance directly into the moments where time disappears, such as prioritization, preparation, routing, and drafting so adoption feels natural and can be measured. You can prove impact with a small set of metrics like cycle time, throughput, dollars collected, and hours saved, and iterate from there.

Key takeaways

Modernizing collections is about fixing the fundamentals first, before you add AI into the mix. As you begin to streamline your own finance workflows, keep these lessons in mind:

• Fix fragmented workflows before adding intelligence: AI delivers the most value when it’s layered on top of standardized processes and a unified data foundation rather than disconnected systems and ad hoc handoffs.
• Embed assistance where time is actually lost: Copilot-style support works best when it shows up directly in prioritization, preparation, routing, and drafting to reduce friction without changing how people work.
• Focus AI on high‑ROI decisions, not just automation: Predicting late payments, flagging likely invoice disputes, and surfacing context can help teams spend time where it matters.
• Design around the practitioner’s day: When work arrives prioritized and prepped, case managers spend less time chasing context and more time resolving exceptions.
• Measure what matters to prove impact: Cycle time, dollars collected, throughput, and hours saved provide a clear, repeatable way to track productivity gains and cashflow velocity.
• Pair generative AI with strong governance: Trust comes from clear ownership, standardized workflows, quality data, and ongoing human oversight.

Editor’s notes:

• SAP is an enterprise finance system that many organizations use to manage invoices, payments, and financial records in a single, centralized platform.
• All metrics cited are based on Microsoft internal data gathered during the writing of this article. They’re best read as directional signals from that period, and they may change as systems, processes, and behaviors evolve. Microsoft makes no warranties, express, implied, or statutory.

Try it out

• Build and test an AI‑assisted workflow with Microsoft Copilot Studio to see how agents can help prioritize work, summarize context, and route cases more efficiently.
• Start a Dynamics 365 free trial.

Related links

• Discover the five lessons we learned on how to make AI stick for sellers during our Copilot rollout.
• See how we revamped and modernized our Microsoft Treasury infrastructure using Azure.
• Explore how we’re supercharging our support experience with Microsoft Dynamics 365 and AI.
• Learn how we’re transforming the marketing function at Microsoft with AI.
• Read about our role as Customer Zero in an AI-powered world.
• Check out how we’re measuring the impact of Microsoft 365 Copilot and AI internally.

The post Streamlining finance cash collection at Microsoft with AI appeared first on Inside Track.

But in practice, the technical side of transformation is only part of the story. The missing piece is us humans.

When we encounter these kinds of challenges internally at Microsoft, we think of ourselves as “Customer Zero.” We roll out our technology across our own organization first, learning what works and what doesn’t in real time and at scale so we can pass our lessons on to you.

“After an early wave of enthusiasm for Copilot, adoption declined. People questioned whether AI was relevant to their role, worried about what it might mean for their work, and disengaged when the change they experienced didn’t match the change they imagined.”

Daniel Bertrand, senior director, AI Transformation Office

We learned valuable lessons about AI adoption and sustainable change when we deployed Microsoft 365 Copilot across our Microsoft Commercial organization, one of the company’s largest sales and service organizations. What we observed led us to reset our strategy and build a more human-centered process for deploying and driving adoption of our AI technology.

Driving AI adoption with role relevance and daily habits

Here on the Customer Zero team in Microsoft Customer and Partner Solutions (MCAPS), our 60,000-employee strong sales organization, we saw that getting access to Copilot didn’t automatically result in widespread AI adoption.

“After an early wave of enthusiasm for Copilot, adoption declined,” says Daniel Bertrand, a senior director on the AI Transformation Office team in MCAPS. “People questioned whether AI was relevant to their role, worried about what it might mean for their work, and disengaged when the change they experienced didn’t match the change they imagined.”

Initially, people used Copilot like a search engine and expected it to make work go away. When that didn’t happen automatically, they didn’t know how to approach prompting the AI, or how to create value with it. The gap between access and know‑how is where adoption slowed.

“I knew from experience that people prefer to hear from—and learn alongside—those closest to their day-to-day work, to build trust and confidence.”

Susan Neece Robien, senior director of adoption and change, AI Transformation Office

We reframed the problem from “How do we scale the technology?” to, “What does this change feel like for people doing the work every day?”

By talking to people in our larger organization about why they were reluctant to work with Copilot, we discovered the adoption barrier was less about the technology being available and more about whether people trusted it, understood how it fit their role, and felt confident enough to build new habits around it.

The ‘Adoption-in-a-Box’ approach

After these conversations, we changed our strategy across the board.

“I knew from experience that people prefer to hear from—and learn alongside—those closest to their day‑to‑day work, to build trust and confidence,” says Susan Neece Robien, a senior director of adoption and change on the AI Transformation Office team. “That led me to conceptualize Adoption‑in‑a‑Box—a repeatable approach that combines behavior‑change guidance, peer influence, habit‑forming activities, and light gamification so people can experiment with AI in a non‑threatening way and build confidence over time.”

We rolled out the Adoption-in-a-Box concept across the team in the following ways:

• Emphasized visible leadership support: We circulated videos and “day in the life” PowerPoint 1-pagers of how our leaders were using Copilot.
• Formed a community of early adopters: They becamepeer champions for adoption, evangelizing best practices and leading workshops.
• Created a Role Hub: The hub contained practical, role-specific learning about how to use Copilot rather than doing high-level general trainings.
• Ran prompt campaigns: To get our team started with habitually using AI in their daily roles, we ran prompt campaigns to make prompt learning accessible and actionable.
• Created the Copilot Cup: We encouraged friendly competitions with leadership support. We also ran hackathons and prompt-based scavenger hunts to gamify learning about and using the AI for our team.
• Created ongoing measurement mechanisms: We stood up dashboards with monthly, weekly, and daily average usage reports. We also ran quarterly surveys to track sentiment around AI adoption on the team.

After our initial success with Adoption-in-a-Box, we scaled it to adoption leads, who brought the model to life within their teams.

When people feel safe in experimenting with AI and incorporating it into their day-to-day work, that’s when it provides real value for the organization and the individual. We’ve learned that sustainable, scalable AI transformation succeeds when we put people first.

Key takeaways

If you’re wondering how to encourage your own team to adopt new AI technology into their workflows, you can learn from our experience:

• Prioritize visible leadership participation. Leaders set the tone of any transformation, and AI adoption is no exception.
• Roll out for role relevance. Specificity is the key here: How does AI relate to each person’s individual role? If the tool provides value and saves time, people will incorporate it into their workflow.
• Establishing habits is crucial. Sustainable adoption means people use the tool on a daily basis in the natural flow of their work. Give them low-friction opportunities to learn the ropes.
• Encourage peer-to-peer experimentation. Early adopters can be a valuable resource for showing others the way. Lowering the stakes by having a peer guide employees in a workshop or one-on-one can take the pressure off as they experiment with the tech.

Try it out

Test drive an AI-assisted workflow of your own with Microsoft 365 Copilot to see how agentic AI can transform your team.

Related links

• Discover the five lessons we learned about how to make AI stick for sellers during our Copilot rollout.
• Check out our full guide describing how we deployed and drove adoption of Microsoft 365 Copilot across our global organization.
• Read about our internal change management strategy for Copilot and how it helps us drive the future of work.
• Learn how the creation of a Copilot Expo propelled AI usage at Microsoft.
• See our seven tips for driving Copilot adoption with a virtual skilling event.
• Discover how one Microsoft Digital employee powers her typical workday using Copilot.

The post Staying human: How we’re using AI to transform the sales experience at Microsoft appeared first on Inside Track.

Geoff Belknap, CVP and operating CISO shares the questions he asks when considering when and how to integrate technologies with a merged or acquired company.

Key takeaways

Think about moving slowly with early integration with M&A. Here are some key questions to consider:

• What do we risk by combining tools or technical capabilities too quickly?
• Is the deal still valuable if we do not integrate systems?
• What operational safeguards and governance are needed?

The post Microsoft CISO advice: Consider the risks of early integration with mergers and acquisitions appeared first on Inside Track.

• Introduction: Governance in the age of AI
• Chapter 1: Enable self-service
• Chapter 2: Establish container labels and set well-scoped, intuitive defaults
• Chapter 3: Derive file labels from parent containers
• Chapter 4: Train employees
• Chapter 5: Trust employees, but verify their work
• Chapter 6: Implement lifecycle management and attestation
• Chapter 7: Enable company-shareable links
• Chapter 8: Extract inventory to detect and report oversharing
• Conclusion: The way forward

Governance in the age of AI

Unlocking the next generation of productivity tools

Microsoft 365 Copilot combines the power of large language models (LLMs) with your organization’s data to turn employees’ words into some of the most powerful productivity tools on the planet—all within the flow of work. It suffuses the Microsoft 365 apps your people use every day—including Word, Excel, PowerPoint, Outlook, Teams, and more—to provide real-time intelligent assistance.

Findings from workplace surveys that we did internally here at Microsoft show that AI tools are having a significant and measurable impact across some of our major business functions:

Getting governance right

With all the opportunities AI presents, your organization might be in the process of implementing Microsoft 365 Copilot. But it’s important to do that safely.

Copilot combs through your organization’s entire data estate in the blink of an eye, so the old method of security through obscurity doesn’t cut it. You need to assert control over where data flows throughout your tenant, so Copilot knows what it can and can’t access or display.

Learn from our Microsoft 365 Copilot experience

We learned a lot as the first large enterprise to deploy Microsoft 365 Copilot. We used those learnings to create this deployment and adoption guide that you can use at your company—check it out:

• View our full Microsoft 365 Copilot deployment and adoption guide. 
• View a condensed version of the guide, designed for executives. 

To ensure that proper data hygiene extends to AI-powered workflows, Microsoft designed Copilot to respect the sensitivity labels and data loss prevention (DLP) controls that organizations configure in their Microsoft Azure environment. That way, administrators can be confident that the right people and apps have access to the data they need, and that sensitive information doesn’t appear where it shouldn’t.

Our team in Microsoft Digital, the company’s IT organization, created a company-wide governance strategy to address this challenge. In the process, we learned valuable lessons that will be useful to any organization using Copilot.

“We’re entering an age where AI amplifies human capability at unprecedented scale, and the integrity of our data determines the integrity of that transformation. Thoughtful governance ensures that we balance adoption with risk to enable the business.”

Brian Fielder, vice president, Microsoft Digital

This guide outlines our process for developing and implementing a governance strategy that delivers the benefits of Copilot to Microsoft employees while minimizing the risks to our data estate. We share our internal learnings so our customers can get up and running quickly while avoiding pitfalls or surprises.

Follow along to find out how you can safely and effectively deploy Copilot at your organization—backed by rock-solid governance.

“We’re entering an age where AI amplifies human capability at unprecedented scale, and the integrity of our data determines the integrity of that transformation,” says Brian Fielder, vice president of Microsoft Digital. “Thoughtful governance ensures that we balance adoption with risk to enable the business. AI accelerates possibility and does so with clarity, confidence, and unwavering trust.”

Principles for effective AI governance

Use this set of tips to ground yourself as you read through this guide:

Enable self-service. Give employees the ability to create new workspaces across your Microsoft 365 applications. By maintaining all data on a unified Microsoft 365 tenant, you ensure that your governance strategy applies to any new workspaces.

Limit the number of information protection labels. Try to limit your taxonomy to a maximum of five parent labels and five sub-labels. That way, employees won’t feel overwhelmed by the volume of different options.

Use intuitive labels that mean what they say. Make your labels simple and legible. For example, a “business-critical” label might imply confidentiality, but every employee’s work feels critical to them. On the other hand, there’s very little doubt about what “highly confidential” or “public” mean.

Capture container labels for groups and sites. Label your data containers for segmentation to ensure your data isn’t overexposed by default. Consider setting your container label defaults to the “Private: no guests” setting.

Derive file labels from parent containers. Classify files according to their parent containers. That consistency boosts security at multiple levels and ensures that deviations from the default are exceptions, not the norm.

Train employees. Train your employees to handle and label sensitive data to increase accuracy and ensure they recognize labeling cues across your productivity suite.

Trust employees, but verify their work. Trust your employees to apply sensitivity labels, but also verify them. Check against DLP standards and use auto-labeling and quarantining through Microsoft Purview automation.

Implement lifecycle management and attestation. Use strong lifecycle management policies that require employees to attest containers, creating a chain of accountability.

Consider your default link-sharing configuration. Limit oversharing at the source by allowing company-shareable links—at least as secondary options—rather than forcing employees to add large groups for access. For highly confidential items, limit sharing to employees on a need-to-know basis.

Extract inventory to detect and report oversharing. Use Microsoft Graph Data Connect extraction in conjunction with Microsoft Purview to catch and report oversharing after the fact. When you find irregularities, contain the vulnerability or require the responsible party to repair it themselves.

Learn more

How we did it at Microsoft

• See how we’re riding the wave of agents washing over Microsoft with good governance. This story shares how we established our initial policies and matrixed governance model for agents.
• Explore our IT playbook for the AI era and learn how we’re becoming a Frontier Firm. This article shares our journey as an IT organization in support of this new operating model.
• Read our five-step guide for IT leaders who want to drive greater AI maturity. This resource can help you chart a course through AI maturity to reimagine what’s possible for the enterprise.
• Discover how Microsoft is becoming an AI-first Frontier Firm. This story shares how we’re approaching the idea of an “agentic future.”

Further guidance for you

• Secure your agents at scale with Microsoft Agent 365 guidance for unified identity, compliance, and control across platforms.
• Learn about the Responsible AI policies and practices that we use to guide our use of AI at Microsoft.

Chapter 1: Enable self-service

Empowering employees with secure self-service

Applying self-service principles to the way we manage labeling and governance emerged as a crucial step for us. 

Self-service is a core tenet of employee empowerment here at Microsoft. We want to give every employee the independence to create the resources they need without engaging IT. But that level of freedom relies on ensuring our Microsoft Digital governance team identifies and protects valuable data. As a result, our employees can implement and own the containers, workspaces, and content they need to do their work productively. 

A container or workspace is a logical unit of content storage associated with a designated roster of collaborators. Common containers include SharePoint sites, Viva Engage communities, Outlook groups, and Teams channels.

Self-service forms the foundation of our entire governance strategy. Employees can create workspaces and content across many of the Microsoft tools they use for their day-to-day work, including SharePoint, OneDrive, Teams, and Power Platform. That freedom enables a culture of innovation and agility, where people can work together across teams and geographies without encountering “IT gating,” the need for IT to get involved in enabling day-to-day activities.

By encouraging collaboration in place, our tenant structure frees employees from resorting to email attachments or working in overly broad and open workspaces. As an IT team ourselves, we understand the value of eliminating IT gating for minimizing the time and effort our professionals need to invest in keeping employees productive.

This kind of data hygiene isn’t just about Microsoft 365 Copilot. It maintains data security and compliance wherever employees access company content and information. But because Copilot depends on the ability to access an organization’s data estate, good governance is essential for keeping it within bounds—especially in a self-service culture.

Here are the key pillars of our asset governance:

• Support self-service creation
• Use lifecycle management
• Offer user education and awareness/trainings
• Implement monitoring and auditing
• Adopt insider risk management

• Require classification for containers
• Scan with Microsoft Purview Data Loss Prevention and Information Protection services

• Limit reach
• Enforce policy
• Use conditional access or multifactor authentication
• Apply Microsoft Purview Data Loss Prevention and Information Protection services

• Manage group or site ownership
• Review external membership
• Generate reports

Responsible self-service

Self-service container creation has abundant benefits, but it also poses some challenges for content governance and security—things like oversharing, unneeded asset sprawl, and data leakage. To address these challenges, our Microsoft Digital governance team has established self-service principles that balance the needs of employees and the company.

We empower with accountability

Accountability has responsibility. Any full-time employee can create a workspace, but they’re responsible for re-attesting its compliance every six months to ensure it meets our governance requirements. They also need to attest that they still require and maintain the resource. They need to manage their own content and ensure it’s properly classified, labeled, and secured. The content’s accountable owner makes any decisions about the workspace with respect to reach or the desire to maintain it. That removes any guesswork for IT about whether a site is still valued and cared for.

We empower with guardrails

We secure assets by default and expand access based on employee needs.

We trust, but we also verify

Microsoft Information Protection (MIP) sensitivity labels and Purview DLP act as guardrails for employee-led governance efforts.

As we in Microsoft Digital have worked to improve the company’s overall governance posture, we’ve learned several important lessons. When you consider self-service container creation, there are a few questions to ask yourself:

• Who do you trust to create containers? At Microsoft, we reserve complete self-service capabilities for full-time employees. Then, we configure those privileges in Microsoft Entra ID to define who can create Microsoft 365 Groups. These users need to take relevant trainings, and we hold them accountable for the containers they create.
• Where does employee self-service make sense? Different employees will require self-service in different environments. Will yours need to operate within SharePoint? Power Platform? Teams?
• What are your lifecycle rules? Think about your policies and rule sets. Who’s accountable? What does the lifecycle look like?
• What are your naming rules? A clear taxonomy can act as an extra signpost and organizational driver for your users. It can also be useful to think through what names are explicitly helpful or obscure. At Microsoft, we use a blocked word list, but we don’t prefix or suffix all groups or site names to avoid overloading the employee experience.

When you’ve settled on degrees of autonomy and where to apply it, you can begin your AI governance journey. Find out how to configure containers for self-service.

Key takeaways

Use these tips—which are based on what we learned here at Microsoft—to enable self-service in Copilot governance at your organization:

• Front-end load on building your strategy. Put thought into your environment and tenant architecture, key personas, and scenarios before adoption.
• Account for hesitancy. Understand that IT organizations have inherently cautious habits, and self-service might seem like a leap. As you lay out the business value for self-service container creation, illustrate the safety backstops as well. Also consider the risks if you don’t take this step, like employees misusing existing sites or other means not supported by IT.
• Bring leadership on board. Make the business case and offer reassurances that greater flexibility doesn’t equal greater vulnerability.
• Assess your current setup. Consider your existing data hygiene and how it needs to extend to accommodate AI.

Learn more

How we did it at Microsoft

• Read how we’re powering data governance at Microsoft with Purview Unified Catalog. This article explains how we centralized data governance and improve data discoverability at scale with the Purview Unified Catalog.
• Discover how we’re riding the wave of agents washing over Microsoft with good governance practices. This post explores how we established strong governance practices to safely enable the rapid adoption of AI agents across the organization.

Further guidance for you

• Get an overview of pre-deployment preparation for Microsoft 365 Copilot. This guide outlines the key pre‑deployment steps organizations can take to ensure Microsoft 365 Copilot is secure and compliant.
• Learn about our Copilot Success Kit, a one-stop shop for most of our Copilot deployment and adoption resources. This resource walks through a centralized collection of tools, guidance, and best practices for deploying and adopting Copilot.
• Learn more about Microsoft Purview Data Loss Prevention and Microsoft Purview Data Governance, which are key to our organization’s approaches for protecting sensitive information and managing data assets throughout their lifecycle.

Chapter 2: Establish container labels and set well-scoped, intuitive defaults

Balancing freedom with trust through an easy-to-use labeling taxonomy

Self-service container creation forms the foundation of our employee-centric governance strategy. As part of that freedom, our Microsoft Digital governance team has established baseline protections inherent to all containers, and those protections depend on sensitivity labels. Microsoft 365 Copilot respects labels, so establishing effective labeling practices extends data security into our employees’ AI usage.

Baseline labeling habits

Employees need to label every container or workspace they create using Purview Information Protection (PIP) container labels. It’s a matter of policy at Microsoft: If it isn’t labeled, we delete it. We use container labeling for data delineation and to apply consistent protection and governance policies to containers based on their sensitivity and purpose.

Microsoft labels break out into four different categories:

• Highly confidential. This is our most critical data. Employees can only share this with specifically designated recipients.
• Confidential. This is sensitive business data that’s crucial to achieving our goals. Employees should limit distribution to a need-to-know basis.
• General. The “General” label includes data we use and share throughout Microsoft, like personal settings and postal codes. They’re visible internally throughout Microsoft.
• Public. Public data is unrestricted and suitable for open, external consumption. It includes open-source code or financials the company has announced. Employees can share this data freely.

Container labels provide two things:

• First, they drive user awareness over how to handle content. For example, if something is highly confidential, employees shouldn’t talk about it in the café.
• Second, they illustrate what data is appropriate for which container. In other words, they signal to an employee that they shouldn’t store highly confidential documents on a general site.

Our Microsoft Digital governance team predefines and centrally manages labels to align them with broader MIP sensitivity levels used for email, files, meetings, and containers. Those include the same four categories: “highly confidential,” “confidential,” “general,” and “public,” although we don’t use the last one for containers.

Matching labels with policies and protections

Each label we’ve defined has a set of protection settings that include policies around characteristics like guest allowance and membership openness. They also drive inherited file labeling, which we use for encryption.

At its core, container classification communicates four things:

• Privacy level: Labels determine whether the workspace is broadly available internally or it’s a private site.
• External permissions: We administer guest allowance via the group’s classification, allowing specified partners to access teams when appropriate.
• Sharing guidelines: We tie important governance policies to the container’s label. For example, can employees share this workspace outside Microsoft? Is this group limited to a specific division or team? Or is it restricted to specific people? The label establishes these rules.
• Conditional access: While not implemented at Microsoft, tying identity and device verification to container labels introduces additional governance controls.

After extensive experimentation, we arrived at our current schema for how container sensitivity labels align with MIP policies. Your organization might make different choices about your labels’ relationships with information protection policies, but this graphic can give you an idea of what a healthy governance ecosystem looks like:

Building a process around employee ownership

The labeling process works like this: When employees create a new container, they’re responsible for selecting a container label that matches the sensitivity and purpose of the content they intend to store and share. By default, we lock new containers, which means that only the owner and members can access them. Locked containers prevent unauthorized or accidental access to their content.

Container owners can unlock the container if they need to share content with a broader audience within the organization or external partners. Container owners can also change the container label if the sensitivity or purpose of the content changes over time.

At Microsoft, this process provides the right combination of flexibility and protection while empowering employees with effective self-service.

Key takeaways

Here are some of the main insights we’ve gleaned from our own data-labeling practices, which you can apply to your efforts in this area:

• Use intuitive labels. Your employees will be the ones applying labels, so make those labels intuitive. For example, “highly confidential” is easy to understand, while “business-critical” can be interpreted many ways from a sensitivity standpoint.
• Make use of existing defaults. Identify the security needs and regulatory compliance that are specific to your organization and use built-in governance controls available through Microsoft tools.
• Limit the number of labels to 5×5. Keep labels minimal to avoid overtaxing your employees’ understanding. We recommend restricting your labeling schema to no greater than five main labels with five sub-labels each—and the fewer, the better!
• Pilots are powerful. Experiment with sensitivity labeling through a small group of early champions, then roll these features out alongside an adoption and education initiative.

Learn more

How we did it at Microsoft

• Learn how we create self-service sensitivity labels in Microsoft 365. This article covers how we designed and implemented self‑service sensitivity labels to empower employees while reducing administrative overhead.
• Find out how we’re using sensitivity labels to make Microsoft more secure. This post examines how we use sensitivity labels with built‑in guardrails to strengthen security without slowing down employee productivity.

Further guidance for you

• Read about getting started with sensitivity labels. This documentation introduces the core concepts, setup steps, and capabilities of sensitivity labels in Microsoft Purview.
• Explore how to apply sensitivity labels to your files. Read a guide on how to apply sensitivity labels to files and emails across Microsoft 365 apps.

Chapter 3: Derive file labels from parent containers

Using default file-labeling based on container labels

We’re helping our teams stay consistent with how they create and store resources by making sure that default file-labeling happens based on container labels. Here’s how that looks for our employees:

1. SharePoint and other containers support default library labels, which we configure to align with the container label through mapping we define in Purview.
2. For instances where we need to define default library labels for tools that don’t have container labels, like OneDrive for Business, we create custom scripts. For OneDrive, we “secure by default” by using a default label like “Confidential\Internal-only,” which means that any file type that supports protection will remain protected–even if it’s accidentally left behind on a device, emailed externally, or purposefully shared externally. Without lowering the label, the default protection will not be decryptable by external actors.
3. By default, new items that are unlabeled inherit the label of the container that stores them. That helps employees apply the correct label and avoid misclassification. For example, if an employee creates a new document in a SharePoint site labeled “confidential,” the document will automatically receive that label.
4. Employees can change the item label if the sensitivity or purpose of the content differs from the container label. But that only works in one direction; they can’t store files with higher-confidentiality labels in a lower-confidentiality container. For example, they can downgrade a file in a “highly confidential” container to “general” if it doesn’t require heightened protection, but they can’t upgrade a file in a “general” container to anything above that grade. SharePoint will provide warnings to site owners when it detects label mismatches—for example, when a file label is more sensitive than its container’s.

The following graphic shows how default file-labeling is impacted by container labels and other sharing limitations:

By defaulting file labels to their container labels, you can ensure that every item and collaborative space will align with both its context in your organization and your information protection policies. As a result, Copilot will respect those labels and their corresponding information protection policies.

Key takeaways

Here are some key tips for setting up container-file relationships, based on what we’ve learned through our own experience here at Microsoft:

• Communicate the relationship between files and containers. Employees might not understand the relationship between files and their containers intuitively. When you implement your labeling strategy, be sure to include education about container-file derivation.
• Guide through correction. Many employees learn best from practice, not instruction. Include automated messages that correct edge-case behaviors like trying to make a file in a confidential container generally available.
• Ensure you’re comfortable with your label defaults. Employees will more often than not use the default, so ensure your defaults are correct and reflect your organization’s needs.
• Reinforce the importance of file labels. Because a file can be moved or downloaded from its original container, the only way to protect that information is to ensure its label remains durable. Embed that durability in your object label configurations.
• Match container and file label defaults. Whenever possible, make the container and file defaults the same from the outset. If you start with different labels or policy sets at the outset, it will be difficult to reconcile those changes later.

Learn more

How we did it at Microsoft

• Find out how we’re using sensitivity labeling as a new layer of security for Microsoft Teams Premium meetings. This post explains how we apply sensitivity labels to content in Teams Premium to protect sensitive collaboration.

Further guidance for you

• Learn more about configuring default sensitivity labels in SharePoint libraries. This guidance details how default sensitivity labels in SharePoint libraries ensure consistent protection for our stored content.

Chapter 4: Train employees

Empowering our employees: A joint effort between IT and users

Training your employees on how to handle and label sensitive data continues to be a critical step on our governance journey. 

Establishing a robust labeling strategy is only part of good governance. When it comes to getting employees on board, culture is as critical as policy.

At Microsoft, employee learning and development are how we move sensitivity labeling from the administrative sphere into day-to-day practice. It helps us increase the accuracy of how our labels are used and ensures that our employees recognize labeling cues when they appear across our productivity suite.

Every incoming Microsoft employee takes our Standards of Business Conduct and security trainings. As part of that process, we created an internal SharePoint resource dedicated to educating employees about their responsibilities for labeling and adhering to our governance policies. It educates employees about the philosophy behind our policies, shares a simplified overview of our sensitivity label structure, and provides practical, app-specific guidance for self-service labeling.

Effective learning and development assets

As you build out your employee education assets, consider emulating our content with the following elements:

1. Overview

It will be much easier for employees to act according to your governance policies if they understand what the policies do and why they’re so important. Our overview illustrates the relevance of sensitivity labeling for security and compliance and reinforces our employees’ role in maintaining them.

2. A quick-reference guide

A visual guide will help employees understand how labels relate to each other and what they accomplish. At Microsoft, we use a helpful flowchart that provides an outline of our labeling taxonomy without overloading employees with details. Placing it near the beginning of your training content grounds employees in the knowledge early, before they dive deeper into the details.

3. Technical education

Our learning material includes a section on how labeling works within our data estate. Then, it proceeds into an in-depth description of how each label or classification interacts with users’ content. Including this section will make labeling more tangible for your employees.

4. App-specific guidance

At this point, our guidance documentation progresses through the most common app-based use cases for sensitivity labeling: Microsoft 365 files, Teams, Power BI, and PDFs, as well as AIP and other file types separate from Microsoft 365. This app-by-app procedural content will help employees home in on their most common scenarios and educate themselves accordingly.

Aside from laying a solid foundation as an IT team, the most effective way to promote good governance is by bringing your workforce on board. Robust learning and development content is a powerful lever for establishing a culture of data security.

Key takeaways

Here are some of the key insights we’ve drawn from our own employee training in Copilot governance, which can guide you as you set up your own trainings.

• Educate from day one. People will only do what they know, so ensure employees know your policies and how to enact them. Build robust education into your labeling and governance strategy, ideally as part of employee onboarding.
• Don’t neglect in-app education opportunities. Labeling cues are an excellent opportunity for helping employees remember their responsibilities. Make label descriptions brief and tangible during in-app experiences.
• Provide education on-ramps. Nobody’s memory is perfect. Link out to relevant information as part of label descriptions so curious employees have a chance to reinforce their knowledge.
• Engage actively and situationally. If breaches occur or certain teams underperform, coordinate with relevant managers to refresh employee knowledge.

Learn more

How we did it at Microsoft

• Find out how we’re deploying Microsoft 365 Copilot with the help of—you guessed it—Copilot. This article explains how we used Copilot itself to plan, deploy, and scale Microsoft 365 Copilot across the organization.
• Discover how we’re skilling up our employees for the future of work with Agent Launchpad. This post covers our latest training program to help our workers get the most out of agentic AI.

Further guidance for you

• Learn more about sensitivity labels. This Microsoft Learn content provides an overview of sensitivity labels, including how they help classify, protect, and govern sensitive data across Microsoft 365.

Chapter 5: Trust employees, but verify their work

Self-service with guardrails: Backstopping our employee efforts with technology

Trusting your employees while also verifying that their actions are secure via automation is a crucial step. 

Thanks to our education efforts and intuitive labeling interfaces, we trust employees to apply sensitivity labels. But we also verify their work. It’s how we catch the 1% of edge cases where problems might arise.

We accomplish that by checking files against our data-loss prevention (DLP) standards and using auto-labeling and quarantining when we need them. Swiftly tying up any loose ends eliminates wayward items that Microsoft 365 Copilot might scoop up during the course of its work. Another way we verify employee decisions is by asking them to provide a reason when they downgrade a security label.

Data-loss prevention (DLP) is a set of technologies and practices centered around Microsoft Purview that help detect, monitor, and reduce the risk of sensitive data being inappropriately shared or accessed.

At Microsoft Digital, we use Purview DLP policies to define the rules and actions for detecting and protecting sensitive data across Microsoft 365, SharePoint, OneDrive, and Teams.

DLP policies support vulnerable data types and scenarios that require protection. They include any kind of information that might introduce inappropriate access to company data or intellectual property:

• Access credentials like keys or tokens
• Personally identifying information
• Financial data
• Non-public source code
• Sign-in information

Reports and dashboards are available via Purview to help our team monitor and analyze content activity and compliance across the organization. They also provide insights into the volume, location, and usage of sensitive data, as well as any incidents and alerts that indicate potential data breaches or violations.

For example, an employee might label something as “General,” but it contains credentials or other sensitive end-user identification information (EUII). In those instances, Purview will automatically block the file from access beyond its owner or reapply a more appropriate label.

Automation and escalation

We’ve configured Purview to automatically remediate these kinds of issues or escalate them to our Microsoft Digital governance team for resolution when an issue is more complex. DLP remediation and escalation processes can involve several different groups of stakeholders depending on the severity and impact of the incident or alert:

• Content owners
• Content champions
• The MIP team
• Our legal team
• Security

We use Microsoft 365 Purview to run DLP remediation operations at scale.

1. DLP systems acquire telemetry from the Microsoft 365 activity management API. Backend processing cleanses the data to build relevant insights and surface them through Power BI dashboards.
2. We flag information about files and aggregate it at the file level, then assign it to the last modifier for remediation action.
3. If users don’t act on the files quickly, the DLP team scopes risky sites to quarantine any files with vulnerabilities.
4. All activities—including sharing, labeling, and changing labels—get written into the unified audit log and into Sentinel to monitor for possible risks.

Fortunately, all these features and functionalities are available out of the box through Microsoft 365 and Purview. After you’ve established your labeling strategy and policies, it’s just a matter of adding guardrails to your self-service environment. By automating information protection through quarantining content or rightsizing its label, you can keep Copilot from making sensitive information available where it shouldn’t.

Key takeaways

Here’s what we’ve learned from our trust and verification process, which can inform your own process:

• Consider your key escalation partners. When human intervention is necessary, it’s important to have immediate access to the relevant stakeholders. Assemble your list and build it into your process.
• Understand DLP’s limitations. Purview DLP is a powerful set of capabilities, but it still relies on automation, which can miss things humans don’t. For example, DLP might not understand the code name for a product and fail to catch it during automated verification.
• Identify and manage exceptions. There are very few absolutes in IT, so you’ll always need exceptions. For example, finance professionals will often need to include passwords or credit card numbers in working documents, so we exempt them from Purview DLP oversight with that team. At Microsoft, we use exemption groups to exempt certain employees.
• Involve experts. Your legal, HR, and security teams will be key allies in this process. Engage them early to help you flesh out risk factors and vulnerabilities.

Learn more

How we did it at Microsoft

• Learn how we’re empowering our employees with generative AI while keeping the company secure. This story explores how our employees use generative AI tools in their work while maintaining strong security, compliance, and governance controls.
• Discover how we’re using Purview Unified Catalog to power data governance at Microsoft. This post describes how we use Purview Unified Catalog to centralize data governance and improve visibility and trust in data assets.

Further guidance for you

• Find out how Microsoft Purview Data Loss prevention can help you automate remediation. This guidance outlines how Microsoft Purview DLP helps organizations identify, monitor, and automatically remediate risky data activities.
• Explore how Microsoft Sentinel provides cloud-native security and event management. This overview explains how Microsoft Sentinel delivers security and event management to help detect, investigate, and respond to threats at scale.

Chapter 6: Implement lifecycle management and attestation

Pairing trust with accountability: How we’re maintaining our data hygiene with attestation

We focused on strong lifecycle management policies and employee attestation to help us get our lifecycle management right. 

Attestation and self-service go hand-in-hand. In simple terms, it means employees can create what they need, but they’re accountable for its upkeep. In turn, that chain of accountability makes sure Copilot only accesses clean and appropriate data.

To support this, SharePoint now offers both activity‑based and non‑activity‑based attestations through SharePoint Advanced Management, giving organizations flexible ways to validate that their containers are being properly maintained. Microsoft Entra also provides an inactive group expiration policy that requires renewal of any inactive Microsoft 365 Group (like a team, group-connected site, or Outlook group).

At Microsoft, we follow the principle of data minimization. That means only content that’s necessary and relevant for the company’s operations and objectives should exist in storage. Data minimization reduces the risk of oversharing content that isn’t cared for by employees, minimizes asset sprawl, halts data leakage, and improves quality and usability.

To implement this principle, we require that every existing container has attestation. By extension, we delete information that doesn’t have a full-time employee to care for it or that has become stale or irrelevant.

Attestation is the process of verifying and validating the existence, ownership, and purpose of a container and ensuring it complies with content governance and security policies.

At Microsoft, we require attestation from a full-time employee for all shared workspaces every six months to confirm several aspects of their containers:

• It’s correctly labeled.
• Users actually care about its ongoing existence.
• The roster of people with access is accurate and necessary.
• Sharing capabilities are appropriately restrictive or permissive.
• It complies with corporate retention guidelines.

If a container or an item doesn’t have attestation, we consider it orphaned or abandoned, and it’s subject to deletion. Note that we archive deleted items over an extended period, in case our employees decide they need them after the fact.

Managing exceptions

If a container is subject to a retention or hold for our legal team, that supersedes any deletion event. Generally speaking, containers where the legal team is the accountable owner aren’t subject to re-attestation because we handle those lifecycles more granularly based on Purview retention policies.

Ultimately, every organization will have to decide what makes the most sense for them. Applying these principles will help you maintain organization-wide data hygiene, which prevents over-access from Copilot.

Key takeaways

Here are some tips that come from our experience managing the product lifecycle for Microsoft 365 Copilot here at Microsoft.

• Choose a meaningful attestation interval. The attestation interval should be short enough that it doesn’t introduce risk through neglect and long enough that it isn’t unnecessarily burdensome for employees. Think about what makes the most sense for your people by analyzing their behaviors.
• Communication is key. Be sure that the attestation requests you create for employees contain both the objective for motivation and simple instructions. That will increase buy-in and smooth the process.
• Base non-compliance response on severity. The severity of non-compliance will vary based on different files and containers. Some might be more relaxed, and others more strict. Determine a strategy for deciding which is which.
• Include reasonable resolution and recovery options. Consider your resolution and recovery intervals after a lapse in attestation. You’ll need to balance between items’ sensitivity, employees’ bandwidth, and the infrastructure cost of extended archiving for recoverable items.

Learn more

How we did it at Microsoft

• Check out our guide for deploying and driving adoption of Microsoft 365 for executives. This executive-level guide explains how we deployed Microsoft 365 Copilot and drove adoption across the organization.

Further guidance for you

• Find out how to configure the expiration policy for Microsoft 365 groups. Read how expiration policies help to manage the lifecycle of Microsoft 365 groups.
• Learn about managing site lifecycle policies. This documentation outlines how to manage SharePoint site lifecycle policies to govern site creation, retention, and deletion.

Chapter 7: Enable company-shareable links

Enabling fluid, secure collaboration: Extending access with company-shareable links

We’re finding that the best way to reduce oversharing is by addressing it at the source.

At Microsoft Digital, we recognize that content sharing is essential for collaboration and productivity. Employees need to share content with both internal and external audiences. But that also poses a risk of content oversharing when employees expose material to more people or for longer than necessary. It might also mean they’ve shared content without proper protection or classification.

In many cases, employees need to share content outside its container. That might include simply sharing a specific file outside of the container’s roster to enable collaboration in place without resorting to making a copy of the file. On the other hand, someone might need to email the file as an attachment.

Using company-shareable links

We limit oversharing at the source by enabling employees to directly share with users or groups, or by using company-shareable links (CSLs) for all SharePoint sites and items (except ones labeled “highly confidential”).

A CSL is a type of link that allows anyone who receives it within our organization to access the content. CSLs are convenient and easy to use, and they promote a culture of openness and transparency.

Before CSLs, employees were forced to share content with large security groups, because they didn’t know which groups contained everyone who needed access and manually adding every unique user was too cumbersome. That behavior leads to oversharing, because anyone with access can stumble on the content in Microsoft Search or via an answer from Copilot. Any Microsoft 365 discovery scenario will security-trim results, so it’s important that users can’t directly access things they don’t need.

While employees can pass a company-shareable link around within the company, it isn’t discoverable in Microsoft Search or Copilot, because only users who received the link directly via email or chat will have pre-granted access. It might seem counterintuitive that a CSL is more secure, but it eliminates the need for standing access to content and provides greater protection.

Finally, we allow content owners to modify or revoke CSLs if their sensitivity or purpose changes, or if sharing is no longer necessary. The content owner can also set an expiration date or a password for their link to enhance security and control.

Note that company-shareable links are no longer the default option, but they are still available as a sharing option for the reasons outlined here.

Extra protection for highly confidential items

Our governance team at Microsoft Digital determined that we should enable CSLs by default for all containers and items labeled “public,” “general,” or “confidential.” As a result, employees can share content with their colleagues without having to grant individual permissions or manage access requests.

There are some kinds of content that employees absolutely shouldn’t share through a company-shareable link. The risk emerges if someone copies the link into an open location like a broadly accessible document or community. You’ll have to decide where to draw that line for your organization. At Microsoft, we’ve elected to disable CSLs for all containers and items that are labeled “highly confidential.”

At Microsoft, highly confidential items require need-to-know access for specific people. For these files, employees use links they designate for specific people, which allows access to only individuals the content creator or owner explicitly identifies. In those situations, large security groups aren’t appropriate in any case.

We also want to drive broad sharing to SharePoint, so we discourage CSL use on OneDrive by automatically implementing expiration policies on OneDrive-created CSLs.

These policies compel employees to think about who needs access to content and to take deliberate action before sharing. In some ways, the policies act as an extra gate or prompt to keep our people security-conscious during the sharing process.

At Microsoft Digital, we tailored our policies to the company’s specific needs, but it provides a blueprint for other organizations to build a CSL strategy. Deciding what should be sharable and how will help you ensure robust information protection that’s still flexible enough to foster collaboration and productivity.

Key takeaways

Here are some key learnings we took from our CSL strategic work at Microsoft, which you can apply to your own efforts in this area:

• Establish thresholds for company-shareable links or specific-people links. Align your CSL policies with the sensitivity labels that meet your organization’s security needs. Above a certain threshold, it might make sense to require links for specific people.
• Embed education in the process. Employees will need time to get used to this structure. Create education communications early in the process, and configure your labeling interface to display information about the sharing implications of different labels.
• Manage expectations for security teams. CSLs are counterintuitive in terms of safety. They might make security professionals uncomfortable because employees are free to share them internally with anyone. Reinforce that CSLs are safer than giant security groups, which will be the other default behavior for employees. And unlike security groups, they won’t show up in Microsoft Search.
• Build data hygiene on good defaults. Most people will take the simple path, so make the simple path the safe path. Generally speaking, employees leave the defaults intact. If CSLs are your default, that’s the behavior it will drive for your employees.

Learn more

How we did it at Microsoft

• Check out our guide for deploying Microsoft 365 Copilot. This guide details our approach for deploying Microsoft 365 Copilot, from technical readiness to adoption and value realization.

Further guidance for you

• Find out how company-shareable links work in Microsoft 365 environments. This Microsoft Learn content explains how organization‑wide sharing links affect access, security, and collaboration.

Chapter 8: Extract inventory to detect and report oversharing

Remediating oversharing errors when they occur: Reporting on broad-access files and sites with Microsoft Graph Data Connect

When oversharing does slip through, it’s important to have systems in place to catch it. 

In spite of our Microsoft Digital governance team’s best efforts to limit oversharing at the source, it can still occur. In some ways, it’s inevitable.

Organizations are made up of people, and so will always be vulnerable to human error. Left unchecked, content oversharing can have negative consequences for an organization, including data breaches, compliance violations, or reputational damage. It will also give employees access to content through Copilot that isn’t appropriate.

To detect and mitigate content oversharing, we use Microsoft Graph Data Connect to report on every broad-access file or site with more sensitive labels. It helps us access and analyze data from Microsoft 365, SharePoint, OneDrive, and Teams using Azure Data Factory, Azure Synapse Analytics, or Azure Machine Learning. We then connect those datasets in our data estate using Azure Synapse Spark and track how many SharePoint sites and items are currently overshared based on our business rules.

One of the principal benefits of Microsoft Graph Data Connect is accessing the information we need through each of these technologies in a secure and scalable way, with control governed by our tenant admins.

Note that there will always be cases where we create exemptions to sharing limits. The policies around these exemptions are laid out as part of our Enterprise Governance, Risk, and Compliance guidelines.

Reporting for accountability

Our tenant’s data team uses Microsoft Graph Data Connect to generate reports on every file or site on the tenant with a broad access level, like a CSL or link that can be shared with anyone. It also monitors any item with a sensitive label like “confidential” or “highly confidential.”

These reports provide information and insights on the content’s owners, recipients, activity, and content protection and compliance status. They also help identify and prioritize potential cases of content oversharing.

At Microsoft, this output is helpful for several groups of stakeholders:

• We share the reports with the content champions responsible for reviewing and validating any cases of content oversharing.
• We use the reports to contact and educate the content owners on how to resolve oversharing issues and comply with our governance and security policies.
• We share the reports with the legal and security teams responsible for investigating and responding to cases of content oversharing that involve legal or security risks and incidents.
• We track our improvement over time as we enforce policies on our assets.

To help customers benefit from this kind of visibility, we’ve created a freely available reporting template. We encourage you to use this tool to track oversharing.

Beyond weaving your Microsoft Graph data connect and data export into your own data estate, you can now also use SharePoint Advanced Management in SharePoint Premium to get a list of sites that meet a set of criteria that you select. We use this capability to find all of our sites that share Highly Confidential data to more than 5,000 users. We then use the same capabilities to selectively require our site owners to fix any anomalies we discover.

Get more information on this data access functionality in SharePoint from Microsoft Learn.   

With the right controls and policies in place, you can minimize the number of oversharing errors your employees commit. But when errors do occur, a proactive detection strategy quarantines the risk from Copilot, even as your staff stays connected and collaborating.

Key takeaways

Some of the things we learned about setting up an oversharing detection and reporting system included:

• Select the tools that work best for you. Between Microsoft 365 and Azure, it’s likely you already have access to the tools you need to set up your reporting apparatus. Explore out-of-the-box functionality before building your own solution.
• Get reports to the right people. Collaborate with stakeholder teams to nominate point people who will receive oversharing reports and take action or communicate findings.
• Put thought into your communication strategy. Work with internal comms professionals to determine the best communication strategy when you detect oversharing, especially when speaking with content owners.
• Consider the content of your reports. Different stakeholders will require different information. Work with individual teams to determine what their reports should look like.

Learn more

How we did it at Microsoft

• Find out how we’re powering a generational shift in IT at Microsoft with AI. This article explores how we’re using AI to transform IT operations across the company.

Further guidance for you

• See how you can set up your Microsoft Graph Data Connect reporting apparatus. This resource explores how Microsoft Graph Data Connect enables large‑scale reporting and analytics across Microsoft 365 data.

“As AI becomes woven into the fabric of how we work, governance is no longer just an operational requirement—it’s a strategic imperative.”

David Johnson, principal architect, Microsoft Digital

The way forward

Getting governance right in the age of AI

The advent of AI tools like Microsoft 365 Copilot is a once-in-a-generation development. At this point, we’re still learning all the ways that these tools can be used to unlock creativity, productivity, collaboration, and innovation.

But we can be sure of one thing: implementing them securely and effectively should be priority one.

“As AI becomes woven into the fabric of how we work, governance is no longer just an operational requirement—it’s a strategic imperative,” says David Johnson, a principal architect in Microsoft Digital. “When we pair powerful tools like Copilot with thoughtful oversight, we ensure that innovation accelerates our mission without compromising our security or our values.”

If you’re deploying Copilot to your organization, the lessons we’ve learned at Microsoft Digital can act as a roadmap for your own journey.

Ultimately, the most important thing is to consider the data implications of AI assistance and plan accordingly. Diligence and forethought will make sure your employees get all the benefits of next-generation AI technology while your organization stays protected.

Welcome to the age of AI.

Key takeaways

This guide reflects what we learned as we set up and implemented our governance processes during our internal rollout of Microsoft 365 Copilot. Here are some overall insights to keep in mind when establishing governance controls at your own organization.

• Build governance on intentional design, not inherited habits. Thoughtfully define your tenant architecture, sensitivity labels, lifecycle policies, and container defaults to create a governance environment that is both secure and scalable.
• Empower secure self‑service. Give employees the freedom to create the workspaces they need, backed by intuitive labeling and clear accountability for the content they manage.
• Keep labeling simple, consistent, and enforced by defaults. Use a minimal, intuitive sensitivity label taxonomy and rely on container‑based default labeling to ensure that files stay consistently protected wherever they go.
• Trust users—but verify with automation. Use Purview DLP, auto‑labeling, quarantining, and escalation workflows to catch exceptions and prevent sensitive data from being exposed through Copilot.
• Maintain data hygiene with lifecycle management and attestation. Require regular re‑attestation, remove stale or unowned content, and use SharePoint Advanced Management to support both activity‑based and non‑activity‑based attestations.
• Make collaboration safer with thoughtful sharing defaults. Use company‑shareable links (CSLs) and clear link‑sharing policies to reduce oversharing while still enabling fluid, secure collaboration.
• Detect oversharing proactively and remediate quickly. Use Microsoft Graph Data Connect and SharePoint Advanced Management reporting to surface broad‑access content, notify owners, and correct issues before Copilot surfaces inappropriate data.

Learn more

• Read our guide for IT leaders who want to drive greater AI maturity.
• Discover how Microsoft is becoming an AI-first Frontier Firm.
• Find out how we’re powering agentic adoption at Microsoft as Customer Zero.
• Explore the many resources we’ve prepared to help with Microsoft 365 Copilot adoption.
• Check out our full Microsoft 365 Copilot deployment and adoption guide. 
• Learn about the Responsible AI policies and practices that we’ve established at Microsoft.

Try it out

Get your organization and data ready for Microsoft 365 Copilot.

The post How we’re tackling Microsoft 365 Copilot governance internally at Microsoft appeared first on Inside Track.

Yonatan Zunger, CVP and deputy CISO for Microsoft, suggests focusing exclusively on hardening a piece of software to security threats may make it difficult to use and introduce a new risk when users get frustrated and try to bypass controls. This is why engineers need to consider not just individual components but how they work together to maintain productivity.

“Think of every system as a socio-technical system containing many parts, and all of them working together in unison have to be secured,” Zunger says.

Learn from our experience 

Read our practical advice about applying security fundamentals to AI.

Try it out

Read more from Zunger about applying security fundamentals to AI.

Related links

• Explore more from Zunger about how to deploy AI safely.
• Discover what you need to know about governing autonomous agents.
• Learn about aligning user, developer role, and organizational intent in agent governance.
• Find out how to use Authorization Fabric to govern AI agents at scale.
• Read about agent abuse patterns.
• Identify ways to secure AI agents with Azure AI Foundry.
• Explore how Data Security Posture Management for AI can prevent runtime risks.

The post Microsoft CISO advice: Apply engineering fundamentals to securing AI appeared first on Inside Track.

“It turns out that it’s very easy to write AI-powered software, but it’s very hard to write AI-powered software that works right in real-world cases,” says Yonatan Zunger, CVP and deputy CISO for Microsoft.

Yunger explains how important it is to test if you want to build trustworthy agentic AI.

Learn from our experience 

Read our practical advice about applying security fundamentals to AI.

Key takeaways

Here are best practices to apply while building trustworthy agentic AI:

• Prototype. Test. Iterate. Think of and try prompts your real users might give your agentic AI. Use real data. From those trials, build a set of test cases and keep testing.
• Use AI tools to amplify testing. Evaluating agents requires a “try it and repeat it” mindset. Using AI Foundry with such tools as Python Risk Identification Tool amplifies these assessment capabilities.
• Record your tests. Applying this practice, as you would with unit testing, enables you to repeat evaluations as your data models and agents evolve.
• Don’t skimp on testing. Test early, test often, test with real data. This is the best way to understand what your agent might do when it encounters the unexpected.

Try it out

• Find out how to deploy Python Risk Identification Tool (PyRIT).
• Explore how to use Microsoft Foundry Playgrounds to test your AI solutions.

Related links

• Read more about how to secure agentic AI.
• Learn more from Zunger about how to deploy AI safely.
• Discover what you need to know about governing autonomous agents.
• Explore how to use Azure AI Foundry to secure generative AI models.
• Generate synthetic data for fine-tuning in Microsoft Foundry.
• Leverage built-in policies for model deployment in Microsoft Foundry.

The post Microsoft CISO advice: How to build trustworthy agentic AI appeared first on Inside Track.

“Make it an expectation in your organization that people will create safety plans and have them for everything,” Zunger says. “People get so excited about having clarity in front of them that they end up making much more systematic, careful plans, and the rate of errors goes down dramatically.”

Learn from our experience 

Read our practical advice about applying security fundamentals to AI.

Key takeaways

Here are questions and ideas to consider as you create a safety plan for your AI systems:

• Define the problem. What problem are you trying to solve? A simple and clear problem statement is always a great starting point before building anything, including an AI agent.
• Outline the solution. What is the basis of your solution? Can you explain your solution to an end user? What does a developer or administrative user of your solution need to know about what it is and does?
• List the things that can go wrong. What can go wrong with your solution? Creating this list is the first step to figuring out how to deal with those issues.
• Document your plan. What is your plan to address identified concerns? Identify the process you will follow when something goes wrong.
• Draft your plan early and update it as your solution matures. Your safety plan can be as simple as a list or outline and should evolve as you prepare to build your solution.
• Get feedback and buy-in. When you review the plan with stakeholders and leaders in your team and organization, you may uncover risks or issues you had not thought of. You also build awareness and agreement on what to do when something goes wrong.
• Make a template and build its use into your processes. This tip is for anyone who leads a team or influences process development. Encourage using a safety template in all your projects to bring clarity and structure to how you work with AI.

Try it out

Discover how to secure agentic AI.

Related links

• Learn more from Zunger about AI security fundamentals.
• Zunger shares one important thing to consider when securing AI. 

The post Microsoft CISO advice: The importance of a written AI safety plan appeared first on Inside Track.

Zunger and his team focus on AI safety and security. They consider all the different ways anything involving working with AI can go wrong.

“An important thing to know about AI is that AI’s make mistakes,” Zunger says. “You already know how to work with systems that make mistakes, get tricked.”

Explore Zero Trust for AI

Check out our new Zero Trust for AI tools and guidance.

Try it out

Explore how to extend Zero Trust principles to AI.

Related links

• Discover how to secure and govern autonomous agents.
• Find out how to deploy AI safely.
• Learn about aligning user, developer role, and organizational intent in agent governance.
• Review why it is important to eliminate high privilege access by applications. 
• Meet the Deputy CISOs who help shape Microsoft’s approach to cybersecurity. 

The post Microsoft CISO advice: The most important thing to know about securing AI appeared first on Inside Track.