Yes - You can use sensitivity labels to provide protection settings that include encryption of emails and documents to prevent unauthorized people from accessing this data.

Sensitivity labels

Sensitivity labels from the Microsoft Information Protection solution let you classify and protect your organization's data, while making sure that user productivity and their ability to collaborate isn't hindered.

Example showing available sensitivity labels in Excel, from the Home tab on the Ribbon. In this example, the applied label displays on the status bar:

To apply sensitivity labels, users must be signed in with their Microsoft 365 work or school account.

You can use sensitivity labels to:

• Provide protection settings that include encryption and content markings. For example, apply a "Confidential" label to a document or email, and that label encrypts the content and applies a "Confidential" watermark. Content markings include headers and footers as well as watermarks, and encryption can also restrict what actions authorized people can take on the content.

• Protect content in Office apps across different platforms and devices. Supported by Word, Excel, PowerPoint, and Outlook on the Office desktop apps and Office on the web. Supported on Windows, macOS, iOS, and Android.

• Protect content in third-party apps and services by using Microsoft Cloud App Security. With Cloud App Security, you can detect, classify, label, and protect content in third-party apps and services, such as SalesForce, Box, or DropBox, even if the third-party app or service does not read or support sensitivity labels.

• Protect containers that include Teams, Microsoft 365 Groups, and SharePoint sites. For example, set privacy settings, external user access and external sharing, and access from unmanaged devices.

•Extend sensitivity labels to Power BI: When you turn on this capability, you can apply and view labels in Power BI, and protect data when it's saved outside the service.

• Extend sensitivity labels to assets in Azure Purview: When you turn on this capability, currently in preview, you can apply your sensitivity labels to assets such as SQL columns, files in Azure Blob Storage, and more.

• Extend sensitivity labels to third-party apps and services. Using the Microsoft Information Protection SDK, third-party apps can read sensitivity labels and apply protection settings.

• Classify content without using any protection settings. You can also simply assign a label as a result of classifying the content. This provides users with a visual mapping of classification to your organization's label names and can use the labels to generate usage reports and see activity data for your sensitive content. Based on this information, you can always choose to apply protection settings later.

In all these cases, sensitivity labels in Microsoft 365 can help you take the right actions on the right content. With sensitivity labels, you can classify data across your organization, and enforce protection settings based on that classification.

What a sensitivity label is

When you assign a sensitivity label to content, it's like a stamp that's applied and is:

• Customizable. Specific to your organization and business needs, you can create categories for different levels of sensitive content in your organization. For example, Personal, Public, General, Confidential, and Highly Confidential.

• Clear text. Because a label is stored in clear text in the metadata for files and emails, third-party apps and services can read it and then apply their own protective actions, if required.

• Persistent. Because the label is stored in metadata for files and emails, the label roams with the content, no matter where it's saved or stored. The unique label identification becomes the basis for applying and enforcing the policies that you configure.

When viewed by users, a sensitivity label appears like a tag on apps that they use and can be easily integrated into their existing workflows.

Each item that supports sensitivity labels can have a single sensitivity label applied to it. Documents and emails can have both a sensitivity label and a retention label applied to them.

What sensitivity labels can do

After a sensitivity label is applied to an email or document, any configured protection settings for that label are enforced on the content. You can configure a sensitivity label to:

• Encrypt emails and documents to prevent unauthorized people from accessing this data. You can additionally choose which users or group have permissions to perform which actions and for how long. For example, you can choose to allow all users in your organization to modify a document while a specific group in another organization can only view it. Alternatively, instead of administrator-defined permissions, you can allow your users to assign permissions to the content when they apply the label.

• For more information about the Encryption settings when you create or edit a sensitivity label, see Restrict access to content by using encryption in sensitivity labels.

• Mark the content when you use Office apps, by adding watermarks, headers, or footers to email or documents that have the label applied. Watermarks can be applied to documents but not email. Example header and watermark:

Need to check when content markings are applied? See When Office apps apply content marking and encryption.

Some, but not all apps support dynamic markings by using variables. For example, insert the label name or document name into the header, footer, or watermark. For more information, see Dynamic markings with variables.

String lengths: Watermarks are limited to 255 characters. Headers and footers are limited to 1024 characters, except in Excel. Excel has a total limit of 255 characters for headers and footers, but this limit includes characters that aren't visible, such as formatting codes. If that limit is reached, the string you enter is not displayed in Excel.

• Protect content in containers such as sites and groups when you enable the capability to use sensitivity labels with Microsoft Teams, Microsoft 365 groups, and SharePoint sites.

You can't configure protection settings for groups and sites until you enable this capability. This label configuration doesn't result in documents or emails being automatically labelled but instead, the label settings protect content by controlling access to the container where content can be stored. These settings include privacy settings, external user access and external sharing, and access from unmanaged devices.

• Apply the label automatically to files and emails or recommend a label. Choose how to identify sensitive information that you want labelled, and the label can be applied automatically, or you can prompt users to apply the label that you recommend. If you recommend a label, the prompt displays whatever text you choose. For example:

https://docs.microsoft.com/en-us/microsoft-365/compliance/sensitivity-labels?view=o365-worldwide

You can use retention policies to define data retention for all documents in a SharePoint site.

Retention policies and retention labels

Retention labels and policies help organizations to manage and govern information by ensuring content is kept only for a required time, and then permanently deleted. Applying retention labels and assigning retention policies helps organizations:

• Comply proactively with industry regulations and internal policies that require content to be kept for a minimum time.

• Reduce risk when there's litigation or a security breach by permanently deleting old content that the organization is no longer required to keep.

• Ensure users work only with content that's current and relevant to them. When content has retention settings assigned to it, that content remains in its original location. People can continue to work with their documents or mail as if nothing's changed. But if they edit or delete content that's included in the retention policy, a copy of the content is automatically kept in a secure location. The secure locations and the content are not visible to most people. In most cases, people don't even need to know that their content is subject to retention settings.

Retention settings work with the following different workloads:

• SharePoint and OneDrive

• Microsoft Teams

• Yammer

• Exchange

When using retention policies and retention labels to assign retention settings to content, there are some points to understand about each. Listed below are just a few of the key points. For a more complete list visit Compare capabilities for retention policies and retention labels.

Retention policies

• Retention policies are used to assign the same retention settings to content at a site level or mailbox level.

• A single policy can be applied to multiple locations, or to specific locations or users.

• Items inherit the retention settings from their container specified in the retention policy. If a policy is configured to keep content, and an item is then moved outside that container, a copy of the item is kept in the workload's secured location. However, the retention settings don't travel with the content in its new location.

Retention labels

• Retention labels are used to assign retention settings at an item level, such as a folder, document, or email.

• An email or document can have only a single retention label assigned to it at a time.

• Retention settings from retention labels travel with the content if it’s moved to a different location within your Microsoft 365 tenant.

• Admins can enable users in the organization to apply a retention label manually.

• A retention label can be applied automatically if it matches defined conditions.

• A default label can be applied for SharePoint documents.

• Retention labels support disposition review to review the content before it's permanently deleted.

Consider the following scenarios. If all documents in a SharePoint site should be kept for five years, it's more efficient to do with a retention policy than apply the same retention label to all documents in that site.

However, if some documents in that site should be kept for five years and others for 10 years, you'd need to apply a policy to the SharePoint site with a retention period of five years. You'd then apply a retention label to the individual item with a retention setting of 10 years.

https://docs.microsoft.com/en-us/microsoft-365/compliance/retention?view=o365-worldwide

Yes - Azure AD supports custom roles.

Create and assign a custom role in Azure Active Directory

Custom roles can be created in the Roles and administrators tab on the Azure AD overview page.

https://docs.microsoft.com/en-us/azure/active-directory/roles/custom-create

Azure Active Directory (Azure AD) role-based access control. Azure AD roles allow you to grant granular permissions to your admins, abiding by the principle of least privilege. Azure AD built-in and custom roles operate on concepts similar to those you will find in the role-based access control system for Azure resources (Azure roles).

https://docs.microsoft.com/en-us/azure/active-directory/roles/custom-overview

As security baseline settings are used only on devices running Windows 10 version 1809 or later, you should advise Oswald that only Windows devices are applicable.

Endpoint security with Intune

When admins want to configure and manage security tasks for at-risk devices, they can go to the Endpoint security node in Intune.

https://www.microsoft.com/en-ca/videoplayer/embed/RE4LTIu?postJsllMsg=true&autoCaptions=en-ca

Manage devices

The Endpoint security node includes the All-devices view, where you'll see a list of all devices from your Azure AD that are available in Microsoft Endpoint Manager.

From this view, you can select devices to drill in for more information, such as which policies a device isn't compliant with. You can also use access from this view to remediate issues for a device, including restarting, start a scan for malware, or rotate BitLocker keys on a Windows 10 device.

For more information, go to: Manage devices with endpoint security in Microsoft Intune.

Manage security baselines

Intune includes security baselines for Windows devices and a growing list of applications, including Microsoft Edge, Microsoft Defender for Endpoint (previously Microsoft Defender Advanced Threat Protection), and more. Security baselines are preconfigured groups of Windows settings that help admins apply recommended security.

As an example, the MDM Security Baseline automatically enables BitLocker for removable drives, automatically requires a password to unlock a device, and automatically disables basic authentication. Admins can also customize the baselines to enforce only those settings and values that are required.

Use policies to manage device security

Each Endpoint security policy focuses on aspects of device security like antivirus, disk encryption, firewalls, and areas such as endpoint detection and response and attack surface reduction, made available through integration with Microsoft Defender for Endpoint.

Endpoint security policies are one of several methods in Intune to configure settings on devices. When managing settings, it's important to understand what other methods being used in your environment can configure your devices, to avoid policy conflicts.

Use device compliance policy

Use device compliance policy to establish the conditions by which devices and users are allowed to access the corporate network and company resources. With compliance policies, admins can set the rules that devices and users must meet to be considered compliant. Rules can include OS versions, password requirements, device threat levels, and more. To learn more, go to: Use compliance policies to set rules for devices you manage with Intune.

Device compliance policies are one of several methods in Intune to configure settings on devices. When managing settings, it's important to understand what other methods being used in your environment can configure your devices to avoid policy conflicts.

Configure Conditional Access

Intune can be integrated with Azure AD Conditional Access policies to enforce compliance policies. Intune passes the results of your device compliance policies to Azure AD, which then uses Conditional Access policies to enforce which devices and apps can access your corporate resources.

The following are two common methods of using Conditional Access with Intune:

• Device-based Conditional Access, to ensure only managed and compliant devices can access network resources.

• App-based Conditional Access, which uses app protection policies to manage access to network resources by users on devices that aren't managed with Intune.

To learn more about using Conditional Access with Intune, go to: Learn about Conditional Access and Intune.

Integration with Microsoft Defender for Endpoint

Intune can integrate with Microsoft Defender for Endpoint (formerly Microsoft Defender ATP) for a Mobile Threat Defense solution. Integration can help prevent security breaches and limit the impact of breaches within an organization.

Microsoft Defender for Endpoint works with devices that run:

• Android

• iOS/iPadOS

• Windows 10 or later

By integrating Intune with Microsoft Defender for Endpoint, organizations can take advantage of Microsoft Defender for Endpoint’s Threat and Vulnerability Management (TVM), using Intune to remediate endpoint weakness identified by TVM.

To learn more, go to: Enforce compliance for Microsoft Defender for Endpoint with Conditional Access in Intune.

Role-based access control with Microsoft Intune

Role-based access control (RBAC) helps manage who has access to the organization's resources and what they do with them. By assigning roles to Intune users, admins limit what they'll see and change. Each role has a set of permissions that determine what users with that role can access and change within your organization.

To manage tasks in the Endpoint security node of the Microsoft Endpoint Manager admin centre, an account must have RBAC permissions equal to the permissions provided by the built-in Intune role of Endpoint Security Manager. The Endpoint Security Manager role grants access to the Microsoft Endpoint Manager admin centre. This role can be used by individuals who manage security and compliance features, including security baselines, device compliance, Conditional Access, and Microsoft Defender for Endpoint.

https://docs.microsoft.com/en-us/mem/intune/fundamentals/role-based-access-control

Azure Policy is used to ensure that your Azure resources comply with your organization's business rules.

Azure Policy

Azure Policy is designed to help enforce standards and assess compliance across your organization. Through its compliance dashboard, you can access an aggregated view to help evaluate the overall state of the environment. You can drill down to a per-resource, or per-policy level granularity. You can also use capabilities like bulk remediation for existing resources and automatic remediation for new resources, to resolve issues rapidly and effectively. Common use cases for Azure Policy include implementing governance for resource consistency, regulatory compliance, security, cost, and management.

Azure Policy evaluates all resources in Azure and Arc enabled resources (specific resource types hosted outside of Azure).

Azure Policy evaluates whether the properties of resources match with business rules. These business rules are described using JSON format and referred to as policy definitions. For simplified management, you can group together multiple business rules to form a single policy initiative. After business rules have been formed, you can assign the policy definition, or policy initiative, to any scope of resources that are supported, such as management groups, subscriptions, resource groups, or individual resources.

Evaluation outcomes

Azure Policy evaluates resources at specific times during the resource lifecycle and the policy assignment lifecycle, and for regular ongoing compliance evaluation. The following events or times will trigger an evaluation:

• A resource has been created, deleted, or updated in scope with a policy assignment.

• A policy or an initiative is newly assigned to a scope.

• A policy or an initiative that's been assigned to a scope is updated.

• The standard compliance evaluation cycle (happens once every 24 hours).

Organizations will vary in how they respond to non-compliant resources. Here's some examples:

• Deny a change to a resource.

• Log changes to a resource.

• Alter a resource before or after a change.

• Deploy related compliant resources.

With Azure Policy, responses like these are made possible by using effects, which are specified in policy definitions.

What’s the difference between Azure Policy and Azure role-based access control (RBAC)?

It’s important not to confuse Azure Policy and Azure RBAC. You use Azure Policy to ensure that the resource state is compliant to your organization’s business rules, no matter who made the change or who has permission to make changes. Azure Policy will evaluate the state of a resource, and act to ensure the resource stays compliant.

Azure RBAC focuses instead on managing user actions at different scopes. Azure RBAC manages who has access to Azure resources, what they can do with those resources, and what areas they can access. If actions need to be controlled, then you would use Azure RBAC. If an individual has access to complete an action, but the result is a non-compliant resource, Azure Policy still blocks the action.

Azure RBAC and Azure Policy should be used together to achieve full scope control in Azure.

https://docs.microsoft.com/en-us/azure/governance/policy/overview

Clint should use Azure Key Vault, which is a centralized cloud service for storing your application secrets.

Azure encrypts data

Espionage, data theft, and data exfiltration are a real threat to any company. The loss of sensitive data can be crippling and have legal implications. For most organizations, data is their most valuable asset. In a layered security strategy, the use of encryption serves as the last and strongest line of defence.

Encryption on Azure

Microsoft Azure provides many different ways to secure your data, each depending on the service or usage required.

• Azure Storage Service Encryption helps to protect data at rest by automatically encrypting before persisting it to Azure-managed disks, Azure Blob Storage, Azure Files, or Azure Queue Storage, and decrypts the data before retrieval.

• Azure Disk Encryption helps you encrypt Windows and Linux IaaS virtual machine disks. Azure Disk Encryption uses the industry-standard BitLocker feature of Windows and the dm-crypt feature of Linux to provide volume encryption for the OS and data disks.

• Transparent data encryption (TDE) helps protect Azure SQL Database and Azure Data Warehouse against the threat of malicious activity. It performs real-time encryption and decryption of the database, associated backups, and transaction log files at rest without requiring changes to the application.

What is Azure Key Vault?

Azure Key Vault is a centralized cloud service for storing your application secrets. Key Vault helps you control your applications' secrets by keeping them in a single, central location and by providing secure access, permissions control, and access logging capabilities. It's useful for different kinds of scenarios:

• Secrets management. You can use Key Vault to store securely and tightly control access to tokens, passwords, certificates, Application Programming Interface (API) keys, and other secrets.

• Key management. You can use Key Vault as a key management solution. Key Vault makes it easier to create and control the encryption keys used to encrypt your data.

• Certificate management. Key Vault lets you provision, manage, and deploy your public and private Secure Sockets Layer/ Transport Layer Security (SSL/ TLS) certificates for Azure, and internally connected, resources more easily.

• Store secrets backed by hardware security modules (HSMs). The secrets and keys can be protected either by software or by FIPS 140-2 Level 2 validated HSMs.

Use the various ways in which Azure can encrypt your data to help you secure it whatever the location or state.

https://docs.microsoft.com/en-us/azure/security/fundamentals/data-encryption-best-practices

You should recommend Identity Protection as it is a tool that allows organizations to utilize security signals to identify potential threats.

Identity Protection is a tool that allows organizations to accomplish three key tasks:

• Automate the detection and remediation of identity-based risks.

• Investigate risks using data in the portal.

• Export risk detection data to third-party utilities for further analysis.

Microsoft analyses 6.5 trillion signals per day to identify potential threats. These signals come from learnings Microsoft has acquired from their position in organizations with Azure AD, the consumer space with Microsoft Accounts, and in gaming with Xbox.

The signals generated by these services are fed to Identity Protection. These signals can then be used by tools such as Conditional Access, which uses them to make access decisions. Signals are also fed to security information and event management (SIEM) tools, such as Sentinel, for further investigation.

Identity Protection categorizes risk into three tiers: low, medium, and high. It can also calculate the sign-in risk, and user identity risk.

A sign-in risk represents the probability that a given authentication request isn't authorized by the identity owner. Sign-in risk can be calculated in real-time or calculated offline using Microsoft's internal and external threat intelligence sources. Listed below are some of the sign-in risks that Identity Protection in Azure AD is able to identify:

• Anonymous IP address. This risk detection type indicates sign-ins from an anonymous IP address; for example, a Tor browser or anonymized VPNs.

• Atypical travel. This risk detection type identifies two sign-ins originating from geographically distant locations, where at least one of the locations may also be atypical for the user, given past behaviour.

•Malware linked IP address. This risk detection type indicates sign-ins from IP addresses infected with malware that is known to actively communicate with a bot server.

• Unfamiliar sign-in properties. This risk detection type considers past sign-in history to look for anomalous sign-ins. The system stores information about previous locations used by a user and considers these "familiar" locations. The risk detection is triggered when the sign-in occurs from a location that's not already in the list of familiar locations.

• Password spray. This risk detection is triggered when a password spray attack has been performed.

• Azure AD threat intelligence. This risk detection type indicates sign-in activity that is unusual for the given user or is consistent with known attack patterns based on Microsoft's internal and external threat intelligence sources.

A user risk represents the probability that a given identity or account is compromised. These risks are calculated offline using Microsoft's internal and external threat intelligence sources. Listed below are some of the user risks that Identity Protection in Azure AD is able to identify:

• Leaked credentials. This risk detection type indicates that the user's valid credentials have been leaked. When cybercriminals compromise valid passwords of legitimate users, they often share those credentials. This sharing is typically done by posting publicly on the dark web, paste sites, or by trading and selling the credentials on the black market. When the Microsoft leaked credentials service acquires user credentials from the dark web, paste sites, or other sources, they are checked against Azure AD users' current valid credentials to find valid matches.

• Azure AD threat intelligence. This risk detection type indicates user activity that is unusual for the given user or is consistent with known attack patterns based on Microsoft's internal and external threat intelligence sources.

These risk detections can trigger actions such as requiring users to provide multifactor authentication, reset their password, or block access until an administrator takes action.

Identity Protection provides organizations with three reports that they can use to investigate identity risks in their environment. These reports are the risky users, risky sign-ins, and risk detections. Investigation of events is key to understanding and identifying any weak points in your security strategy.

After completing an investigation, admins will want to take action to remediate the risk or unblock users. Organizations can also enable automated remediation using their risk policies. Microsoft recommends closing events quickly because time matters when working with risk.

Identity Protection is a feature of Azure AD Premium P2.

https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/overview-identity-protection

Yes – Microsoft Intune be used to manage company-owned devices as well as personal devices.

Prevent data leaks on non-managed devices using Microsoft Intune

If you allow access to company data hosted by Microsoft 365, you can control how users share and save data without risking intentional or accidental data leaks. Microsoft Intune provides app protection policies that you set to secure you company data on user-owned devices. The devices do not need to be enrolled in the Intune service.

App protection policies set up with Intune also work on devices managed with a non-Microsoft device management solution. The personal data on the devices is not touched; only company data is managed by the IT department.

You can set app protection policies for Office mobile apps on devices running Windows, iOS/iPadOS, or Android to protect company data. These policies let you set policies such as app-based PIN or company data encryption, or more advanced settings to restrict how you cut, copy, paste, and save-as features are used by users between managed and unmanaged apps. You can also remotely wipe company data without requiring users enroll devices.

Intune app protection policies are independent of device management. App protection policies let you manage Office mobile apps on both unmanaged and Intune-managed devices, as well as device managed by non-Microsoft MDM solutions.

https://docs.microsoft.com/en-us/mem/intune/protect/data-leak-prevention

ISO 27701 specifies rules and guidance to manage personal information and demonstrate compliance.

Data has become more important than ever. Organizations, institutions, and entire societies generate and rely on data to function on a day-to-day basis. Any manipulation or loss of data can damage organizations, institutions, and societies alike. The sheer scale of data generated and the increasing reliance on it, means data management has become pivotal.

Governments are working hard to protect people by creating regulations (laws) that are designed to protect data through several measures including:

• Granting individuals the right to access their data at any time.

• Granting individuals the right to correct or delete data about them if needed.

• Introducing retention periods that dictate a minimum or maximum amount of time data should be stored.

• Enabling governments and regulatory agencies the right to access and examine data when necessary.

• Defining rules for what data can be processed and how that should be done.

Some regulations also require that data remains protected even if it’s moved between geographic locations. For example, regulations in some countries require that any personal data transferred outside of their borders meets several conditions including:

• The destination country where personal data is to be transferred must be considered to have adequate protections for the data.

• Organizations must create appropriate safeguards, such as specific clauses that must be included in contracts with organizations or bodies that handle any personal data.

Common compliance regulations

Some of the regulations that organizations and institutions commonly work with include:

• Health Insurance Portability and Accountability Act (HIPAA) – introduces rules on how health-related information should be protected.

• The Family Educational Rights and Privacy Act (FERPA) – introduces rules to protect student information.

• ISO 27701 – specifies rules and guidance to manage personal information and demonstrate compliance.

•The General Data Protection Regulation (GDPR)

Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data. This text includes the corrigendum published in the OJEU of 23 May 2018.

https://ec.europa.eu/info/law/law-topic/data-protection/data-protection-eu_en

Microsoft supports organizations’ compliance needs with built-in tools and capabilities to help them protect information, manage data governance, and respond to regulatory requests.

https://docs.microsoft.com/en-us/office365/servicedescriptions/microsoft-365-service-descriptions/microsoft-365-tenantlevel-services-licensing-guidance/microsoft-365-security-compliance-licensing-guidance

Multi-factor authentication is a process where a user is prompted during the sign-in process for an additional form of identification, such as to enter a code on their cellphone or to provide a fingerprint scan.

How it works: Azure AD Multi-Factor Authentication

Multi-factor authentication is a process where a user is prompted during the sign-in process for an additional form of identification, such as to enter a code on their cellphone or to provide a fingerprint scan.

If you only use a password to authenticate a user, it leaves an insecure vector for attack. If the password is weak or has been exposed elsewhere, is it really the user signing in with the username and password, or is it an attacker? When you require a second form of authentication, security is increased as this additional factor isn't something that's easy for an attacker to obtain or duplicate.

Azure AD Multi-Factor Authentication works by requiring two or more of the following authentication methods:

• Something you know, typically a password.

• Something you have, such as a trusted device that is not easily duplicated, like a phone or hardware key.

• Something you are - biometrics like a fingerprint or face scan.

Azure AD Multi-Factor Authentication can also further secure password reset. When users register themselves for Azure AD Multi-Factor Authentication, they can also register for self-service password reset in one step. Administrators can choose forms of secondary authentication and configure challenges for MFA based on configuration decisions.

Apps and services don't need changes to use Azure AD Multi-Factor Authentication. The verification prompts are part of the Azure AD sign-in event, which automatically requests and processes the MFA challenge when required.

https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-mfa-howitworks