I’ve recently been working with a client migrating to Microsoft Teams, including the deployment of physical phones.
Interestingly, while their organisation has a strong focus on data compliance, little attention had been given to the compliance risks of their existing traditional handset-based phone system.
With the Teams rollout, we opened up important conversations around compliance and security.
A full breakdown of Teams compliance requirements is beyond the scope of this short post, but I’ll share some of the basic templates and considerations we use when deploying physical phones—especially in environments subject to standards like ISO 27001 and UK GDPR.
If you’re interested in specific mapping to those standards, I’ve compiled a reference spreadsheet:
CAP_Compliance_ISO27001_GDPR.xlsx
Note: This is based on my own internal notes and not exhaustive— please validate against your own requirements.
Anyway, let’s look at phones. Typically, you have two types of phones in use in your estate:
- Common Area or Shared Phones. These devices are typically used in shared spaces such as reception, lobbies, hallways etc. Meeting room phones are often included in the ‘common area’ name as well, from a structural perspective.
- Personal Phones. These are phones dedicated to a single user – sometimes, they will be used in shared-desk spaces so that different users can logon at different times (traditionally referred to as ‘extension mobility’).
Each of these usage models requires different considerations when it comes to data compliance, so let’s look at them both.
Common Area/Shared Phones
- Licensing. The appropriate licenses should be used instead of ‘full’ user accounts. These should be secured appropriately, and their credentials stored securely.
- User Sign-In to Shared Devices. This should be prevented given that users typically have less restrictive policies. Sign-in can be further restricted using conditional-access type policies to locations (for example) to further ensure the security health of the devices.
- Voicemail. Typically, voice-mail is disabled for these phone devices. Care should be taken enabling voicemail as it would allow any user to access those messages.
- Call History. Most phones will, by default, allow you to view the call history of the phones. This may not be a wanted behaviour – many phone devices will allow this functionality to be disabled.
- Calendar Access. Many modern phones will allow viewing of calendars associated with the room or phone. This may not be wanted behaviour – in a shared meeting room for example, you may not wish people to be able to browse to see who else has been using the meeting room. Many phones allow the disabling of this functionality.
- Directory Search. You may not wish to allow the searching of the corporate directory. You can, in many instances, assign fast dials to common numbers such as reception or media-room assistance for example.
- Class of Service. You may wish to restrict where certain phones can call. All phones should be able to make emergency services calls, however all calling ranges are optional: Internal, national, international, premium rate etc. Some consideration to the dial spaces permissible is required. Class of Service is effectively ‘who can call who’. You will also want to restrict call-forwarding or simultaneous ringing capabilities.
- Call Detail Records (I.e., who calls who, and how) and if required, external Voice Recording. These practices should be enforced so that the full usage of the phones is qualified. Some industries/sectors require full voice-recording of external calls for example, whereas in several environments CDR is often enough.
The above elements can be implemented with most phones such as the Poly devices common within the Microsoft Teams world.
From a general approach, you’re aiming to follow the ISO27001/UK GDPR data-minimization principles.
Personal Phones
User personal devices tend to be used in a different way to common area and will often be placed in dedicated offices or on hot-desk type environments. There are, however, still best-practices to consider when securing the devices. The items you should consider include:
- Conditional Access. This can be used to restrict sign in by location, device compliance, enforce MFA etc.
- First Time Sign-In should enforce MFA.
- Shared Sign-Ins on user devices should be disabled.
- Auto–Lock and PIN. When a user first sets up their phone, they must set a PIN. The phone should also be configured to auto-lock after a period of non-use – this is typically circa 5 minutes for user phones.
- Call Detail Records (I.e., who calls who, and how) and if required, external Voice Recording. These practices should be enforced so that the full usage of the phones is qualified. Some industries/sectors require full voice-recording of external calls for example, whereas in several environments CDR is often enough.
- Contact & Calendar Access Considerations. It is usual to allow access to the user’s contacts and calendar information on personal phones, for both calling and access to meetings etc. This of course offers compliance risks around data access due to unauthorised access etc. This is the key driver around the enabling of the auto-lock/PIN enablement, and conditional access.
- Class of Service. It is becoming less common to restrict the class of service of user based phones, however this may still be a consideration. All phones should be able to make emergency services calls, however all calling ranges are optional: Internal, national, international, premium rate etc. Some consideration to the dial spaces permissible is required. Class of Service is effectively ‘who can call who’. You will also want to restrict call-forwarding or simultaneous ringing capabilities.
Summary
The above is just a brief summary of the items to consider when deploying physical phones in a Unified Communications environment.
