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 (LoB) 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 to clarify 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.
- Information security (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” has different definitions 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
“Device” in BYOD covers a lot of territory. Will your policy be for mobile devices only, such as smartphones and tablets, or 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. Mobile 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 many. Sometimes it’s a very senior manager who insists that they need a different device than everyone else. Or an advanced research and development group that 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. It 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.