Bring Your Own Device (BYOD) policies touch on strongly-held beliefs about the boundary between work and home, not to mention security, access to information, and personal privacy. While searching for “BYOD Policy Example” might be a step in developing a good policy, it shouldn’t be the first step. The process of writing a policy requires more than editing a template — it means establishing a lasting consensus on mobile behavior and security.
Here are five key agreements to make before you dive into writing policy.
1. Agree About Who Is on the Team
Regardless of who is driving the BYOD policy process, a team representing different parts of the organization has to come together to translate strategy into policy. Four primary areas should be represented:
- Line-of-Business Managers: BYOD is about more than giving people access to email — it’s about enabling a more effective organization. The use cases that LoB managers bring to the table help define the structure of mobility.
- Information Technology: BYOD support comes from IT, and IT will have valuable input including potential technical problems. IT can also help make it clear what is, and isn’t, possible with existing infrastructure.
- Administration: BYOD combines a very personal device—typically a smartphone—with company rules and responsibilities. In the long run, HR and Legal departments will be responsible for enforcing the policy and dealing with violations.
- Infosec and Risk Management: If private or financial information is leaked or lost due to BYOD use, that’s an organization-wide problem. Getting the InfoSec team’s input, especially as security settings are being discussed, helps cover all the bases.
2. Agree on the Definition of BYOD
The term “BYOD” means different things to different people. It’s your company and you can make any definition you want, but you should make it clear what you mean early on.
Agree on the answers to these four questions to define the term “BYOD” in the context of your organization:
- Who pays for and owns the device? Who pays for the monthly service plan?
- Who gets to pick the device and what limits are there to this choice?
- Who has the most control over the device: the user or the organization? Is this a personal device that has some enterprise applications? Or an enterprise device that the user can also use for personal use?
- What applications are part of BYOD? Do you include just collaboration tools such as email and calendaring? Or are there other LoB applications as well?
3. Agree on the Kind of Devices Covered
The D in BYOD could cover a lot of territory. Agree on whether this policy is going to be for mobile devices only, such as smartphones and tablets. Are you including laptops? How about user-owned computers, such as home desktop computers?
4. Agree on the Scope of the Policy
Nothing sinks a BYOD policy faster than a lack of balance between user freedom and organizational control. Mobility security policies should be written to acknowledge that most users want a single smartphone, no matter who pays for it. From that point of view, BYOD policies describe a collaboration between the organization and the staff member, working together to ensure that mobile devices don’t represent a security vulnerability.
Trying to assert too much authority will result in users rejecting the policy or subverting its intention. Agree early on how you’ll approach this, and where the organization does, and does not, have control.
5. Agree on the Exceptions
Policies always have exceptions, and BYOD policies often have lots. Sometimes it’s a very senior manager who insists that they need a different device than everyone else. Or an advanced R&D group may need special access to their devices or configuration for testing and development. In any case, there will be exceptions, and it’s good to plan for those exceptions from the beginning. This may sound like you’re already undermining the new policy, but it’s better to have all the rules laid out at the beginning.
Start by identifying who is allowed to make exceptions to the policy — and it shouldn’t be an entire committee. The exception process shouldn’t make it easy to circumvent the policy, but it should allow reasonable exceptions when there are clear business requirements. Exceptions should be clearly documented and be subject to periodic review, or come with an expiration date.
If you can get agreement on these five questions before you start writing the policy, the entire process will be much simpler and painless.