The smallest BYOD policy that survives an audit

A fifteen-person company does not need mobile device management to pass an audit. It needs six things proven once, in writing, with a signature. Here is the smallest version that holds up.

The question comes up constantly: employees read work email on their own phones, nobody wants to buy an MDM, and the auditor is going to ask how that is controlled. The instinct is to reach for a platform. Usually you do not need one.

I have run this at a company that had never had a security function, through a SOC 2 Type II, and the mobile control was six screenshots per person and a signed policy. It held.

Start with who, not what

Not every employee needs the same rules, and pretending otherwise is why BYOD policies get written once and ignored forever.

Somebody in HR with access to personnel files, somebody in payroll, somebody handling proprietary information, somebody on the security team — those people carry different risk than a salesperson reading a calendar invite. Write stricter requirements for them. You can reasonably require a managed device for the handful of people with access to the data that would actually hurt you, and a lighter touch for everyone else.

Doing it this way also makes the stricter rules survivable. Telling five people they need a company phone is a conversation. Telling all fifty is a revolt.

The trust problem is a contract problem

The real blocker on BYOD is almost never technical. It is that people do not want their employer inside their personal phone, and they are right to be cautious.

The common advice is to explain what IT can and cannot see. That is not enough, because a verbal assurance from a manager is worth nothing six months later when a different manager is in the chair.

Put it in writing instead. Enumerate in the BYOD policy exactly what the company can access and exactly what it cannot. Name the specific capability — can the company read personal photos, see browsing history, query device location, wipe the whole phone or only the work container? Then have people sign it.

A signed document people can re-read beats an assurance they have to remember. And it doubles as audit evidence, which is a second reason to do it and the reason most compliance people think of first. Both are good. The first one is what actually gets you adoption.

The six things to prove

For a company without an MDM, ask each person to prove the following on their phone, with screenshots, once:

• Screen lock, PIN or biometricNot a swipe. The single highest-value control on the list, because the overwhelmingly likely incident is a lost phone, not a targeted attacker.
• Up-to-date operating systemA screenshot of the version screen showing a current release.
• Screen timeoutA lock screen that engages on its own, within a few minutes.
• Encryption onModern iOS and Android do this by default once a passcode is set, but have them show it rather than assume it.
• Remote wipe availableFind My on iOS, Find Hub (formerly Find My Device) on Android.
• MFA on company data appsNot just email — the file store, the chat tool, the CRM, anything with customer information in it.

Collect the screenshots, keep them, and you have your evidence. That is the entire control.

One note on remote wipe and location

Remote wipe is the item that causes friction, because enabling it requires location services to be on. On iOS, Find My cannot be turned on without Location Services; Android's Find Hub is the same. There is no way around it.

This is where a lot of BYOD rollouts die, because "turn on location tracking" sounds like surveillance to the person being asked. The framing matters enormously, and it should be in the signed policy, not a hallway conversation:

Location services are enabled so that you can locate and erase your own device if it is lost. The company does not query device location and cannot see where you are.

Same requirement. Entirely different reception. And if your company can query location through whatever tooling you run, say so plainly instead — a policy that misrepresents what the company can see is worse than no policy, because the day someone discovers the gap is the day every other control loses credibility.

Laptops are a different problem

Phones can be handled with screenshots because the controls are few and visible. Laptops cannot — nobody is going to screenshot their firewall profiles, patch level, disk encryption status and local administrator group accurately.

What works there is a read-only audit script: it inspects the machine, writes a report, and changes nothing. The user runs it, reads what came back non-compliant, fixes those settings, and runs it again to prove the fix. You keep both reports.

The objection is always that non-technical staff will not manage it. In practice they will, if the instructions are three lines and the script does not ask them to make decisions. I have had marketing and HR run these without incident. The thing that makes it work is that it only reports — nobody is afraid of a script that cannot change anything.

The part that actually costs you time is not collection, it is reconciliation: fifteen reports, read one at a time, every cycle. That is mechanical, and it should not be done by hand. Drop the whole set into the rollup and you get one compliance matrix, a list naming every machine and what failed on it, and a CSV an auditor will accept.

The script that produces those reports is being prepared for public release, source included — the whole argument for a read-only audit tool falls apart if you cannot read it first.

What this does not cover

Being straight about the limits: screenshots are a point-in-time attestation. They prove the setting was right on the day it was taken, not that it is right today. Someone can turn off their screen lock the following week and you will not know.

That is an acceptable trade for a fifteen-person company and most auditors will take it, particularly alongside a signed policy and an annual re-attestation. It stops being acceptable somewhere around the point where you have enough people that you cannot name them all, or enough regulated data that a single lost phone is a reportable event. At that point, buy the MDM.

Knowing which side of that line you are on is most of the judgment. Buying a platform you do not need is a waste; skipping one you do need is a finding.