Enterprise-level BYOD policy dos and don’ts
There’s no way around it. Your organization needs a Bring Your Own Device (BYOD) policy. In fact, it probably needed it two or three years ago.
You dig in and do your homework. You evaluate the options, assess the upsides, and prepare for potential drawbacks. You’ve taken in tons of advice and information. It’s time to sort through it all. Before you go into information overload, tie up your research with our handy list of BYOD policy dos and don’ts.
Don’t forget the gatekeepers
Your IT team probably has existing precautionary guardrails to protect devices and networks.
That’s a great start. But as the BYOD policy develops, IT administrators need to stay informed and involved.
Their teams are accountable for network security. And they know better than anyone the boundaries that need to be set as part of the policy.
Do be cautious yet flexible
In a post for cybersecurity authority Security Intelligence, New York Times best-selling author and award-winning journalist Bob Sullivan stands firm against opinions BYOD is another tech trend. “Neither BYOD nor IoT is going anywhere.”
“So, what should IT departments do?” Sullivan asks. “The solutions aren’t easy—and they’re going to have to evolve alongside every new gadget and application that connects to the company network.”
Is your BYOD policy putting the responsibility on IT to secure every device on your network?
Remember that this isn’t about limiting or restricting device use. It’s about empowering those entrusted to protect the company’s systems and infrastructure. Make sure these policies support your IT department’s overall BYOD objectives.
“Ensure constant monitoring of approved hardware and software,” Sullivan writes, “Just because your team decides a particular tablet or application is safe today doesn’t mean it won’t be unsafe tomorrow.”
Consider how future technologies might impact security. Is there a good possibility that IT will find itself stretched thin? Will IT end up playing “patch-a-mole” with every new OS update and firmware release? If so, you may want to leave some room in the BYOD policy for a managed IT services provider (MSP) to shoulder the load.
Don’t reinvent the wheel
Your BYOD policy needs to consider your organization’s specific technological needs. Think about the size of your company. Think about the kind of tech that benefits your employees. Identify the types of devices you can do without. Separate the must-haves from the nice-to-haves.
Now that you’ve determined who needs to support and influence your BYOD policy and what types of circumstances it needs to address, the fine folks at IT Manager Daily have done us all a solid and posted a BYOD Policy template.
Just cut it, paste it, and make it your own. Maybe put it on the good company stationary you save for special occasions or prepare to upload it to your human capital management system, but first . . .
Do make sure legal reviews the policy
The policy is ready for release after your legal department has officially vetted it. But you still need their help identifying who’s responsible for communicating what. You need their assistance defining what the company considers adequate communication.
Do you send an email to employees asking them to stay on alert for possible phishing attacks? Or is the company on the hook to provide more comprehensive education? Should employees acknowledge in writing that they understand the new policy?
Defining and enforcing the BYOD policy in these ways can make or break its effectiveness.
This is an instance where it is perfectly acceptable to assume the worst. Employees will reuse passwords. New technology will fail. Legacy tech will stop being patched for current threats. A new hire will log into his laptop at a coffee shop, hop on a free network, and access a bunch of sensitive data without thinking twice.
The legal department is a crucial ally when developing any type of company policy. They’re a key partner in making sure the BYOD policy you craft, draft, and deliver is effective and won’t leave the company exposed if a data breach occurs.