If you work in financial services, healthcare, or another regulated industry, you may have a regulatory obligation to record certain employee communications — including voice calls made through Microsoft Teams. Compliance recording in Teams is fundamentally different from the "Record" button that participants see in a meeting, and conflating the two causes compliance gaps that are difficult to explain to regulators.
This article explains the difference, how compliance recording works technically, and what to think about before deploying it.
Convenience Recording vs Compliance Recording
Convenience recording (sometimes called "ad-hoc recording") is the recording that a meeting participant initiates by clicking the "Record" button. It's stored in the organiser's OneDrive or in a SharePoint channel library. It's subject to meeting policies (the admin controls whether users can initiate it) but is ultimately voluntary and user-initiated.
Compliance recording is different in every important way. It's:
- Policy-based, not user-initiated: Recording happens automatically for designated users based on their policy assignment. Users cannot opt out.
- Stored in a compliance-specific location: Not in OneDrive or SharePoint, but in a compliance recording store managed by the recording solution (typically a third-party recording platform).
- Captured at the media stream level: Compliance recording uses Microsoft's Teams Policy-Based Recording architecture to capture the audio/video stream directly, not a screen recording of the meeting.
- Non-interruptible: Even if a participant tries to leave or end the recording, the compliance capture continues as long as the policy applies.
- Announced in the client: Participants can see that a recording bot is present. Whether that banner satisfies a specific statute is a legal question, not a Teams setting.
- Stored outside Microsoft 365: The recording platform, not OneDrive, holds the file. A retention label on OneDrive will not govern it.
The Microsoft Teams Policy-Based Recording Architecture
Microsoft Teams compliance recording works through a policy-based recording architecture that was introduced several years ago. The mechanism works as follows:
- An administrator creates a compliance recording policy in the Teams Admin Center.
- The policy references a recording application (a certified third-party recording bot) registered in Azure.
- The policy is assigned to specific users (the custodians who need to be recorded).
- When a policy-assigned user joins a call or meeting, the recording bot is automatically invited as a participant and begins capturing the media stream.
- The recorded content is transmitted to the recording platform (third-party or Microsoft's own compliance recording infrastructure).
The key implication: you need a third-party compliance recording solution (or Microsoft's own compliance recording product) to use policy-based recording. This is not built into Teams at no cost; it requires additional licensing and a compatible recording platform. Microsoft maintains a list of certified compliance recording partners in the Teams documentation.
Compliance Recording Policy Configuration
In the Teams Admin Center, compliance recording policies are configured under Voice > Compliance recording policies (in the left navigation under the "Enhanced encryption policies" section in newer Admin Center layouts — check the current navigation as it shifts periodically).
Each policy references a recording application (identified by its Azure app ID) and specifies the recording mode: required (calls are blocked if the recording bot is unavailable), optional (calls proceed even if the bot is unavailable), disabled (recording is off for this policy).
The recording mode "required" is appropriate for environments where regulatory compliance requires that all covered communications are recorded. If the recording system is unavailable and a user covered by this policy initiates a call, the call is blocked rather than proceeding unrecorded. This is the conservative, compliance-safe choice for regulated industries.
Which Calls Are Covered?
Compliance recording policies in Teams can cover:
- Teams 1:1 audio and video calls
- Teams PSTN calls (if Teams Phone is deployed)
- Teams meetings (including ad-hoc meetings, scheduled meetings, and channel meetings)
Compliance recording policies apply to calls where at least one participant is assigned the policy. Whether the recording captures only the policy-assigned participant's audio or all participants depends on the specific recording platform and its configuration. Understand your platform's data capture model before representing to regulators what is and isn't recorded.
Disclosure and Consent Requirements
Most jurisdictions that require call recording for financial or healthcare communications also have disclosure requirements — the other parties must be notified that the call is being recorded. Teams Policy-Based Recording can be configured to play a disclosure announcement at the start of a recorded call. The exact disclosure requirements vary by jurisdiction and by regulation (MiFID II, Dodd-Frank, HIPAA, etc.), so consult your compliance team before relying on Teams compliance recording as your sole disclosure mechanism.
Don't assume that displaying a "Recording in progress" banner in the meeting UI is sufficient for your specific regulatory requirements. Some regulations require verbal disclosure; others require consent. Know your requirements before deployment.
Storing and Searching Compliance Recordings
Compliance recordings are stored in the recording platform's compliance store, not in Teams or OneDrive. Access to recordings for eDiscovery or regulatory review is through the recording platform's interface, not through Microsoft Purview. This is an important difference from convenience recordings (which are stored in Microsoft 365 and searchable through Purview eDiscovery).
Ensure that your chosen compliance recording platform integrates with your eDiscovery workflow and that recordings are subject to appropriate retention policies. The recording platform's retention settings and your Microsoft Purview retention settings need to be aligned so that recordings are kept for the required regulatory period.
When the Recorder Bot Is Busy and the Call Still Connects
Compliance recording for Microsoft Teams is only as strict as the policy mode. In required mode, a call or meeting that cannot attach the recording bot should not proceed for a user covered by the policy. In optional mode, the same failure is a successful call with a missing recording. Regulated teams often think they bought required mode because they bought a recorder. The mode is a separate setting, and optional is a common default on the vendor's starter template.
A brokerage with 200 covered staff moved to Teams Phone and enabled a certified recorder. For two weeks the policy was optional while the vendor finished capacity planning. Calls succeeded. A sample of the recorder's catalogue showed gaps during the busiest hour, when the bot pool was exhausted and the calls continued without it. Nobody had been asked to compare the phone log to the recording catalogue. The comparison, once done, was the moment the mode was switched to required and the bot pool was sized for the peak rather than for the average.
Required mode will block business if the recorder fails. That is the point, and it needs an operational owner: who is paged, how staff are told to place the call another way if the regulation allows a fallback, and how the blocked-call count is reviewed. A required policy with no one watching the failure counter will be turned down to optional during the first outage and left there.
Coverage is per user, not per phone number and not per team. A trader on the policy is recorded. A colleague who joins the same meeting and is not on the policy may still be captured because the bot is in the meeting, depending on the platform. Confirm that behaviour with the vendor in writing before describing it to compliance. "We record the desk" is only true if every person on the desk is assigned the policy, including new joiners in their first week.
Retention of the recording is configured in the recording platform. Align it with the same schedule used for the related chat, and test a retrieval by case id or by user and date. A recording that cannot be found by the helpdesk path counsel will actually use is not retained in any sense that matters. Run that retrieval test before the first real matter, not during it.
New hires in a covered role need the policy on the day they can place a call, not at the end of onboarding. A user with two accounts will be recorded only on the account that holds the policy. Map the accounts before go-live. Meeting recording started with the Record button is not a substitute, and it should not be described as one in the control statement. Test an inbound PSTN call, an outbound PSTN call, and a Teams-to-Teams call. A single test call type leaves the others unverified. If disclosure is played at the start of the call, listen to it on a real handset. A clip that is too quiet is a disclosure that did not happen. Capacity planning uses peak concurrent calls, not the daily average. The bot shortage appears at the peak. Compare call logs to recording logs for the same hour, not for the same day. The gap appears in the busy hour. Required mode should be tested by disabling the bot in a maintenance window on a test user, and confirming the call fails. Write the fallback procedure before the first outage, even if the procedure is "do not place the call". Covered users who change role should lose the policy when they leave the desk, or you will record people you no longer mean to. The disclosure clip should be checked after every vendor upgrade. Upgrades are when audio prompts get dropped. Retention on the recorder should be read back from the recorder's own settings screen, not from the sales proposal. A user on leave still on the policy is correct if their account can still place calls. If the account is disabled, the policy is moot.
