Best practices for maintaining emergency contact information
Hello everyone. Our organization is currently reviewing its emergency contact directory as part of our business continuity and operational processes. What best practices do you recommend for keeping emergency contact information updated and ensuring it remains available during incidents or emergencies? Thank you for your suggestions.
Why “Data in Switzerland” Is Not Enough
Moving from Residency to Control in Microsoft 365 Every conversation about data sovereignty in regulated industries tends to start the same way: “We use Multi-Geo. The data stays in Switzerland.” It’s the right starting point. Microsoft 365 Multi-Geo allows organizations to place selected workloads - SharePoint sites, OneDrive accounts, Teams data, or Exchange mailboxes - into specific regions, including Switzerland, while maintaining a single global tenant. This makes it possible to align sensitive data with regulatory or customer requirements without fragmenting the overall environment. But it only answers one question: Where is the data stored? It does not answer who accessed the data, from where, under which conditions, or what happened after access. That is where the real problem begins. A scenario that happens every day A Swiss engineering firm stores sensitive project documentation in Switzerland using Multi-Geo. An external contractor - working from an unmanaged device outside Switzerland - is granted access to review a file. The document opens. The data is now on a screen in an unknown location, on a device with no compliance posture, in a session with no restrictions. From the platform’s perspective, residency was enforced. From a sovereignty perspective, control was lost the moment access was granted without conditions. The file never left Switzerland. But sovereignty did. Residency is static. Control is not. The moment a document is opened, storage location stops being the relevant boundary. The file is no longer just “in Switzerland.” It moves instantly across endpoints and browsers, collaboration tools like Teams, external users and partners, and increasingly AI-driven contexts. The infrastructure remains unchanged. The data does not. From the platform’s perspective, everything is working as designed - access was granted, residency was enforced - and control was lost. Most “data in Switzerland” strategies fail at exactly this moment: when the data is used. The shift: from location to conditions If data sovereignty is the goal, the question must change. Not “Where is the data stored?” but: Under which conditions can data be accessed and used? This shift fundamentally changes the architecture. Control must be applied across three distinct layers - and all three must be connected. Layer 1: Access is conditional, not static Conditional Access extends control beyond authentication and turns it into continuous evaluation. Access decisions can depend on: Device compliance Location (geo-restriction) Identity and risk signals Multi-Geo ensures data is placed correctly. Conditional Access ensures it is reachable only under defined conditions. The two must work together - residency without access governance is an incomplete control. Layer 2: The session is the real risk surface Even with strict access controls, risk remains. A session is an exposure surface by design. During an active session, data is viewed, copied, shared, processed by applications, and connected to AI prompts. The gap does not appear at storage or authentication. It appears during active usage - inside the session. This is the layer most architectures do not explicitly address. Controls must extend into the session itself: limiting data transfer and replication, restricting interaction patterns, and enforcing policies in real time. Access is no longer a one-time event. It becomes continuously governed. This becomes even more critical as AI assistants consume content across SharePoint, Teams, Exchange, and other Microsoft 365 services. The question is no longer only where the source document resides - but whether the AI interaction itself is governed by the same access and protection controls as direct access. Layer 3: The document becomes the control point The most durable control does not sit in the network or in the session. It sits in the data itself. In regulated industries, organizations often arrive at this architecture having first evaluated sovereign or national encryption solutions. The decision to rely on native Microsoft 365 Purview encryption rather than a separate layer comes down to integration: AES-256 protection operating natively at file, user, and SharePoint level - including geo-based access restrictions - without an additional system to maintain. When protection is applied directly to the document through Microsoft Purview: Sensitivity labels define classification - automatically assigned based on content Encryption enforces access - AES-256, bound to the file itself IRM controls usage - view, copy, print, share, and presentation rights DLP governs movement across services - preventing data from leaving defined boundaries Dynamic watermarking tracks exposure - applied on open, view, or print At that point, access is enforced by the file, usage restrictions travel with it, and control persists regardless of location. The document becomes the perimeter. Platform control: limiting provider access One dimension often overlooked in sovereignty discussions is platform access itself. Even a perfectly configured tenant is only as sovereign as the controls placed on the operator. Customer Lockbox ensures that even Microsoft support cannot access customer data without explicit, logged, time-bound approval. Every access request is visible, auditable, and subject to customer veto. Data control applies not only to users - but also to the platform operating the service. Enforcement requires an integrated architecture Most organizations already have the required capabilities: Multi-Geo, Conditional Access, session control, Purview (labels, encryption, DLP, IRM), and monitoring. The issue is not capability. It is fragmentation. In practice, fragmentation looks like this: residency is configured in one project, Conditional Access policies are managed by a different team, and Purview labels were applied during a compliance initiative that never connected to the access layer. The tools exist. The signals do not flow between them. When designed as a single architecture: Data is placed intentionally - residency aligned to regulatory requirements Access is governed by context - device, location, and identity evaluated continuously Usage is controlled dynamically - session-level restrictions enforced in real time Protection is embedded in the document - encryption and IRM travel with the file Signals are connected across the platform - monitoring feeds access policy, not just audit logs “Data in Switzerland” becomes not just a statement - but an enforceable system property. Closing thought Placing data in Switzerland is the right first step. Multi-Geo makes it possible, even in global environments. But residency alone is not control. Data residency answers where information is stored. Data sovereignty requires proving who can access it, under which conditions, and what controls remain in place after access is granted. In Microsoft 365, sovereignty is no longer defined by geography alone. It is defined by the ability to enforce control wherever the data travels.From “No” to “Now”: A 7-Layer Strategy for Enterprise AI Safety
The “block” posture on Generative AI has failed. In a global enterprise, banning these tools doesn't stop usage; it simply pushes intellectual property into unmanaged channels and creates a massive visibility gap in corporate telemetry. The priority has now shifted from stopping AI to hardening the environment so that innovation can run at velocity without compromising data sovereignty. Traditional security perimeters are ineffective against the “slow bleed” of AI leakage - where data moves through prompts, clipboards, and autonomous agents rather than bulk file transfers. To secure this environment, a 7-layer defense-in-depth model is required to treat the conversation itself as the new perimeter. 1. Identity: The Only Verifiable Perimeter Identity is the primary control plane. Access to AI services must be treated with the same rigor as administrative access to core infrastructure. The strategy centers on enforcing device-bound Conditional Access, where access is strictly contingent on device health. To solve the "Account Leak" problem, the deployment of Tenant Restrictions v2 (TRv2) is essential to prevent users from signing into personal tenants using corporate-managed devices. For enhanced coverage, Universal Tenant Restrictions (UTR) via Global Secure Access (GSA) allows for consistent enforcement at the cloud edge. While TRv2 authentication-plane is GA, data-plane protection is GA for the Microsoft 365 admin center and remains in preview for other workloads such as SharePoint and Teams. 2. Eliminating the Visibility Gap (Shadow AI) You can’t secure what you can't see. Microsoft Defender for Cloud Apps (MDCA) serves to discover and govern the enterprise AI footprint, while Purview DSPM for AI (formerly AI Hub) monitors Copilot and third-party interactions. By categorizing tools using MDCA risk scores and compliance attributes, organizations can apply automated sanctioning decisions and enforce session controls for high-risk endpoints. 3. Data Hygiene: Hardening the “Work IQ” AI acts as a mirror of internal permissions. In a "flat" environment, AI acts like a search engine for your over-shared data. Hardening the foundation requires automated sensitivity labeling in Purview Information Protection. Identifying PII and proprietary code before assigning AI licenses ensures that labels travel with the data, preventing labeled content from being exfiltrated via prompts or unauthorized sharing. 4. Session Governance: Solving the “Clipboard Leak” The most common leak in 2025 is not a file upload; it’s a simple copy-paste action or a USB transfer. Deploying Conditional Access App Control (CAAC) via MDCA session policies allows sanctioned apps to function while specifically blocking cut/copy/paste. This is complemented by Endpoint DLP, which extends governance to the physical device level, preventing sensitive data from being moved to unmanaged USB storage or printers during an AI-assisted workflow. Purview Information Protection with IRM rounds this out by enforcing encryption and usage rights on the files themselves. When a user tries to print a "Do Not Print" document, Purview triggers an alert that flows into Microsoft Sentinel. This gives the SOC visibility into actual policy violations instead of them having to hunt through generic activity logs. 5. The “Agentic” Era: Agent 365 & Sharing Controls Now that we're moving from "Chat" to "Agents", Agent 365 and Entra Agent ID provide the necessary identity and control plane for autonomous entities. A quick tip: in large-scale tenants, default settings often present a governance risk. A critical first step is navigating to the Microsoft 365 admin center (Copilot > Agents) to disable the default “Anyone in organization” sharing option. Restricting agent creation and sharing to a validated security group is essential to prevent unvetted agent sprawl and ensure that only compliant agents are discoverable. 6. The Human Layer: “Safe Harbors” over Bans Security fails when it creates more friction than the risk it seeks to mitigate. Instead of an outright ban, investment in AI skilling-teaching users context minimization (redacting specifics before interacting with a model) - is the better path. Providing a sanctioned, enterprise-grade "Safe Harbor" like M365 Copilot offers a superior tool that naturally cuts down the use of Shadow AI. 7. Continuous Ops: Monitoring & Regulatory Audit Security is not a “set and forget” project, particularly with the EU AI Act on the horizon. Correlating AI interactions and DLP alerts in Microsoft Sentinel using Purview Audit (specifically the CopilotInteraction logs) data allows for real-time responses. Automated SOAR playbooks can then trigger protective actions - such as revoking an Agent ID - if an entity attempts to access sensitive HR or financial data. Final Thoughts Securing AI at scale is an architectural shift. By layering Identity, Session Governance, and Agentic Identity, AI moves from being a fragmented risk to a governed tool that actually works for the modern workplace.
Feedback Opportunity - Enhanced Alert and User Investigation using Copilot for Security in IRM
Summary When investigating alerts within Microsoft Purview Insider Risk Management, you can now utilize Microsoft Copilot for Security. This tool provides concise alert summaries and allows you to delve into specific user activities. This enables you to quickly determine whether the user associated with the alert requires further investigation or if the alert can be safely dismissed. Additionally, with a single click, you can obtain a succinct summary of the user’s risk profile, highlighting crucial details and top risk factors. Leveraging Copilot for Security streamlines investigations, reduces the triage workload, and enables faster decision-making. Use Cases Speeding up the triage and investigation process: Insider risk analysts and investigators can leverage Copilot for Security to quickly summarize alerts and delve into specific user activities, which is especially useful when there is a high volume of alerts. Prioritizing the riskiest alerts and users: Investigators can use Copilot for Security to review the summary of the alert and the associated user’s risk which can help them decide which alerts/users need to be prioritized for further investigation. Learn More Use Copilot to summarize an alert - Investigate insider risk management activities | Microsoft Learn Use Copilot to summarize user activities - Manage the workflow with the insider risk management users dashboard | Microsoft Learn Please share your feedback here - https://forms.office.com/r/g2J9N4JHBY
Whenever login into the office applications different OTP needs to be applied Outlook and teams
When signing into Office applications, a different OTP is required for both Outlook and Teams. To address this issue, there is any resolution this issue supports or a supporting document as proof to confirm that this is a standard procedure.
AIP - running Execute-AzureAdLabelSync appeared to do nothing
Hello I have Azure P1 licensing and M365 Business Premium. I would like to use Purview/AIP for Teams/Sharepoint. The "groups and sites" checkbox is not enabled when creating a new sensitivity label. I followed the steps, connecting with Powershell 7, WinRM as basic, connected to exchange poweshell, etc. I ran "Execute-AzureAdLabelSync" several times. It did not error and returned to the prompt with no feedback. It took maybe 4/10th or a second to run, so long enough to have done something, but no error and no confirmation of success. I am usually good at getting powershell errors, so I know one when I see it. I am running these commands as global admin. This page implies I have the correct license https://docs.microsoft.com/en-us/office365/servicedescriptions/microsoft-365-service-descriptions/microsoft-365-tenantlevel-services-licensing-guidance/microsoft-365-security-compliance-licensing-guidance#information-governance. Any ideas as to what I am doing wrong? thxHow should I enable external collaboration on encrypted Office files
If there is an individual document in SharePoint that I'd like an external party to collaborate on, how can I use sensitivity labels to protect access to the file? In this case, the external party isn't known in advance. I know that I can set up a sensitivity label to encrypt the file and prompts the end user to choose who can access it. The end user would then need to apply that label, grant the right external people access and then share the document with the same people. This process feels prone to error. Is there any option similar to email, so that the end user would just need to share the document and this would also add the recipient to the document's information protection settings?
What are some big Microsoft Azure Security issues we should be aware of now?
Securing cloud environments presents unique challenges. As organizations continue embracing Azure, it's critical to be aware of key security pitfalls. Mastering Azure security best practices is essential for protecting your critical assets in the cloud. Getting the basics right is the foundation - avoid common misconfigurations by using tools like Azure Security Center to lock things down. Implementing multi-factor authentication across the board keeps the bad actors out. The shared responsibility model means you own your data security. Encrypt everything and keep OS and agent versions patched. Reduce your attack surface by locking down management ports and scoping permissions tightly using tools like Privileged Identity Management. Segment your network properly with private endpoints, service endpoints and network security groups. This limits lateral movement opportunities. Of course, remaining vigilant is key. Continuously monitor activity logs, perform penetration testing and use Azure Security Center to get recommended improvements. Cloud security is always evolving. Stay ahead of new Azure features and guidance to keep your environment secure. Mastering these tips will help tame the unique security challenges of the cloud.
New Blog | Supercharge security and compliance efficiency w/ Security Copilot in Microsoft Purview
Today, we are excited to announce AI-powered capabilities in private preview to help your SOC, data security and compliance teams achieve more. With Microsoft Purview capabilities in Security Copilot, your SOC team gains unprecedented visibility across your security data – bringing signals together from Defender, Sentinel, Intune, Entra and Purview into a single pane of glass. Purview capabilities are essential here to help SOC teams determine the source of an attack and quickly identify sensitive data that could be at risk. Read the full blog here: Supercharge security and compliance efficiency with Microsoft Security Copilot in Microsoft Purview - Microsoft Community HubNew Blog | Protect your entire data estate with Microsoft Purview
At Microsoft, we believe that data security is not an afterthought, it is table-stakes. As we unveiled earlier this year, Microsoft is committed to expanding the sphere of protection across the entire data estate. Since that announcement, our teams have been working hard to help customers secure their data wherever it lives. Today, we are excited to share some of the next steps in that journey. In this blog, we will unpack how we are enabling customers to: Gain visibility across their entire data estate Secure structured and unstructured data Detect risks across clouds and apps Read the full blog here: Protect your entire data estate with Microsoft Purview - Microsoft Community Hub
