BYOD Policy: The Ultimate Guide + Free Downloadable Template (2026)

Your security auditor asks: “What controls do you have for employees accessing company data on personal devices?” You pause. Everyone uses their phone to check Slack. Half the team accesses Google Drive from personal laptops. You just have no idea if any of this is written down anywhere.

If that sounds familiar, you’re not alone. And this is the guide that fixes it.

A BYOD policy (Bring Your Own Device) governs how employees and contractors use personally-owned phones, laptops, and tablets to access company data and systems. It defines which devices are permitted, what security controls must be in place, how data is handled on personal hardware, and what happens when a device is lost or an employee leaves. Without one, you have no authority to require security controls, no process for offboarding personal devices, and nothing to show auditors when they ask.

The policy applies to all employees and contractors who access company email, SaaS tools, internal systems, or cloud storage from devices they personally own. It’s owned by the IT or Security lead, with HR as co-owner for acknowledgement and offboarding.

A BYOD policy is expected or required by:

• SOC 2: CC6.7 and CC6.8, which require documented controls over data access and device security
• ISO 27001: Control 8.1 (2022 version) and A.6.2.1 (2013 version), which explicitly require a mobile device policy
• HIPAA: §164.310(d) and §164.312, requiring device controls and encryption for PHI-accessible systems
• GDPR: Article 32, requiring technical safeguards for personal data processing, including on personal devices

By the end of this, you’ll know exactly what to put in your BYOD policy, how to roll it out without a mutiny from your team, and how to map it to compliance frameworks.

Here’s what I’ll cover:

• What a BYOD policy is and who owns it
• Why the absence of one creates real security and compliance risk
• What every BYOD policy needs to include
• A free inline template you can download and use immediately
• How to map it to SOC 2, ISO 27001, HIPAA, and GDPR
• The mistakes I see most often in audits

What Is a BYOD Policy and How Does It Work?

Most companies already have a de facto BYOD programme. Employees check email on their personal phones. They pull up the company wiki from a home laptop. They respond to Slack messages from a tablet at the kitchen table. The question isn’t whether BYOD is happening. It’s whether anyone has written down the rules.

A BYOD policy is the document that defines the terms under which employees and contractors may use personally-owned devices to access company data and systems. It sets eligibility requirements, security controls, acceptable use boundaries, and procedures for incidents and offboarding.

What Is BYOD? The Four Device Models

Not all device programmes are the same. Here’s where BYOD sits in the landscape:

• BYOD (Bring Your Own Device): The employee owns and chooses the device. The company sets security requirements. Most common at early-stage startups.
• COPE (Corporate-Owned, Personally Enabled): The company buys the device. The employee may use it personally. The company has full MDM supervision rights.
• CYOD (Choose Your Own Device): The company offers a list of approved devices. The employee picks one. The company owns it.
• COBO (Corporate-Owned, Business Only): Company device, business use only. Typically used for high-security roles handling regulated data.

The term “bring your own device byod policy” shows up in a lot of compliance documentation and is used interchangeably with “mobile device policy” in most framework contexts.

Who Owns the BYOD Policy?

Primary owner: IT lead, Security lead, or CTO at smaller companies.

Co-owners: - HR: communicates the policy, collects employee acknowledgements, manages offboarding for personal devices - Legal: reviews privacy obligations before MDM deployment (especially important in GDPR jurisdictions)

Review cadence: Annual review at minimum. Also review when you change MDM tools, add a new compliance framework, or have a device-related security incident.

Why Letting Employees Use Personal Devices Creates Compliance Risk

Here’s a situation I’ve heard from founders more than once: an employee leaves the company. Their personal phone has two-factor authentication codes for the production environment. Their laptop has a copy of the customer list they pulled three months ago for a project. You have no policy, no MDM, no way to wipe anything, and no documented authority to ask them to.

That’s the business risk. The compliance risk is simpler: auditors ask for evidence of BYOD controls. Without a documented policy, you have nothing to show them.

Three Security Gaps a Missing BYOD Policy Leaves Open

1. No documented controls. SOC 2 CC6.7 requires documented controls over data transmission and access. If employees access in-scope systems from personal devices and there’s no policy, this is a finding. Every time.

2. No MDM authority. You can’t require employees to enrol their personal device in MDM without a policy that grants that authority and without their consent. No policy means no leverage and no legal footing.

3. No offboarding process. When someone leaves, you can remove their access in Okta or Google Workspace. But if company data sits in their personal cloud backup or in an app on their phone, you have no documented right to remove it. This is an obvious gap in a HIPAA audit.

Personal devices also introduce practical security risks: unpatched operating systems, shared household use, no encryption enabled, no screen lock. The BYOD policy is the mechanism that requires minimum standards before access is granted.

Which Companies and Teams Need a BYOD Policy?

The most common form is a byod policy for employees, covering full-time staff and contractors under one document. If anyone at your company uses a personal device to access email, Slack, Google Drive, GitHub, or any internal tool, you need one. That’s most companies, and it’s almost certainly yours.

It’s especially important if you are:

• Pursuing SOC 2 or ISO 27001. Both frameworks expect documented device controls. This will come up in your audit.
• Handling healthcare data. HIPAA requires documented controls for any device that can access PHI. The “we didn’t know” defence doesn’t exist here.
• Selling to enterprise customers. Enterprise procurement teams and security questionnaires ask whether you have a device management policy. Not having one raises concerns.
• Running a remote or hybrid team. Everyone is accessing systems from personal devices at home. The risk surface is larger, not smaller, in remote-first companies.

Healthcare BYOD Policy Requirements Under HIPAA

A healthcare BYOD policy has to go further than a standard one. HIPAA’s Security Rule requires:

• Device-level encryption (§164.312(a)(2)(iv)) for any device that can access PHI
• Remote wipe capability and documented procedures for device loss (§164.310(d))
• Audit controls: logging who accessed PHI, from which device, and when (§164.312(b))
• A risk analysis that includes personal devices as a documented threat vector

If you’re a healthcare company or a vendor handling PHI, BYOD is not a policy you’ll get away with skipping.

BYOD Programmes in Schools and Education

BYOD in education is a different context from corporate BYOD. Students and staff bring personal devices to access school networks, learning management systems, and cloud tools.

Key considerations: - FERPA governs student education records in the US: personal devices accessing FERPA-protected data must have controls in place - COPPA applies for students under 13: extra restrictions on data collection from personal devices - Network segmentation is essential: student personal devices should be on a separate SSID from staff devices and internal school systems

A byod policy for schools typically covers staff and student use separately, with different security requirements for each group.

BYOD Policy for Small Businesses and Startups

A byod policy for small business doesn’t need to be a forty-page governance document. I’ve seen startups clear a SOC 2 Type 1 audit with a two-page BYOD policy, properly signed, with MDM enrollment records to back it up.

What matters is that it exists, it’s acknowledged, and it’s enforced.

At ten people where everyone uses their own MacBook: a lightweight policy plus Google Workspace MDM (free with your existing Workspace license) is enough for an early-stage audit. A corporate byod policy or byod company policy for a larger SMB will need to go further: reimbursement terms, conditional access, tiered data classification rules, and a formal exception process.

What to Include in a BYOD Policy

Here’s a complete breakdown of every section your BYOD policy should cover, with notes on the areas that most often get done wrong.

BYOD Device Policy: Eligible Devices and Enrollment

The byod device policy section is where most organisations are vague and most auditors push back. “All devices must meet security requirements” tells you nothing. Be specific.

A solid eligible device definition looks like this:

• iOS 16 or later, updated within 90 days of the latest major release
• Android 12 or later, updated within 90 days
• macOS Ventura (13) or later
• Windows 10 or later, with current security patches applied

Enrollment in the company MDM solution is a prerequisite for accessing company systems. Conditional access policies enforce this automatically: a device that hasn’t enrolled or that fails compliance checks is blocked from email, SaaS tools, and VPN. Enrolled BYOD devices should also appear in your asset management policy inventory with device type, OS version, and enrollment status.

BYOD Security Policy: Minimum Technical Controls

The byod security policy section defines the floor. Every enrolled device must:

• Have a PIN or biometric lock enabled
• Auto-lock after no more than five minutes of inactivity
• Have full-disk encryption enabled (on by default on modern iOS and Android; FileVault on macOS; BitLocker on Windows)
• Run an OS version within the organisation’s supported range (align this with your vulnerability management policy patch SLAs)
• Not be jailbroken or rooted (MDM detects and blocks these automatically)
• Use a VPN when connecting to company systems on untrusted networks

BYOD IT Policy: Acceptable Use Rules

The byod it policy section is not just about security settings. It’s about how employees use their personal devices for work.

Prohibited: - Installing work applications from unofficial app stores - Storing company credentials in personal password managers not approved by IT - Uploading company data to personal cloud storage (personal iCloud, Google Drive, Dropbox) - Using personal AI tools (personal ChatGPT, Claude, or similar) to process company or customer data - Allowing third parties to use the device while company data or applications are accessible

Permitted, with conditions: - Personal use of the device alongside work use, provided security settings remain intact - Personal applications alongside managed work applications, provided they don’t trigger MDM compliance failures

Data Handling and Privacy Boundaries

This section is make-or-break for employee adoption. People are suspicious of MDM on their personal devices, and reasonably so. The key is to be explicit about what IT can and cannot see before anyone is asked to enrol.

With work-profile containerisation (Android) or user-enrollment (iOS):

IT can see: device model and OS version, compliance status (PIN, encryption, patch level), apps in the managed work profile, device serial number for tracking.

IT cannot see: personal photos, personal messages, personal emails, personal browsing history, personal app data outside the managed profile.

This privacy-preserving approach draws a clean line between work and personal data. It’s what gets buy-in from employees, and it’s the right default for BYOD.

BYOD Reimbursement Policy: Stipend and Expense Rules

Not every company pays a stipend, and there’s no compliance requirement to do so. But the byod reimbursement policy section needs to address it clearly, whether the answer is “yes, we pay X per month” or “no, we don’t.”

Common approaches:

• Monthly stipend: $30-$75/month for phones, $50-$100/month for employees using a personal laptop as their primary work machine. Simpler to administer.
• Actual expense reimbursement: Employees submit receipts for work-related data costs. More administratively complex.
• No reimbursement: Acceptable, but document it so there’s no ambiguity.

Taxability varies by jurisdiction. In the US, a stipend for documented business use is generally not taxable. In the UK and EU, check with payroll before publishing.

Incident Response and Device Loss

Employees need to know exactly what happens if their device is lost or stolen, and they need to know before they sign the policy.

Define: - Reporting window: 24 hours from becoming aware of the loss is a common standard. - What will be wiped: Work-profile wipe (removes only company data and apps) or full device wipe (removes everything). Work-profile containerisation is the right call for BYOD: it protects personal data. Full device wipe requires explicit upfront consent in writing. - How to report: Contact IT at [IT contact] or via [incident channel].

Free BYOD Policy Template

Below is a complete BYOD policy you can copy, adapt, and publish. Fill in the bracketed placeholders with your company’s specifics. Everything else is pre-populated with security best-practice language.

Sample BYOD Policy Template (Copy and Customise)

The template below is based on the policy structure we use in ComplyJet, adapted as a standalone document. A downloadable PDF version is available via the button below.

How to Write and Roll Out a BYOD Policy

The policy document is not the hard part. The hard part is getting forty people to enrol their personal iPhones in your MDM without pushback. Here’s how to do both.

1. Audit current state. Before writing anything, find out what’s actually happening. Survey which devices employees use to access which systems. This tells you what MDM tool you need and what your real risk surface is.

2. Choose your MDM approach. The choice between work-profile containerisation (recommended for BYOD) and full device supervision (typically reserved for company-owned devices) shapes everything else. Work-profile mode is the right default for BYOD: it preserves employee privacy and gets better adoption.

3. Draft the policy. Use the template above. Customise for your company size, device mix, data classification, and applicable frameworks. If you’re in a GDPR jurisdiction, have legal review the privacy section before publishing.

4. Get leadership approval. The policy must be formally approved, not just written. Document who approved it and when. This becomes part of your audit evidence.

5. Communicate before you mandate. Send the policy to employees before requiring enrollment. Explain clearly what MDM can and cannot see. The number-one reason BYOD rollouts fail is employees feeling surveilled. Being transparent that IT cannot see personal photos, messages, or browsing history removes the biggest objection.

6. Collect acknowledgements. Every employee and contractor in scope must sign that they’ve read and agree to the policy. Log name, date, and policy version. This is the evidence auditors ask for, and it’s where most companies fall short.

7. Run guided enrollment. Don’t just send a link to the MDM enrollment portal. Provide a step-by-step guide per OS. Offer a 30-minute drop-in for anyone who gets stuck.

8. Map to compliance controls. Once the policy is live, document which policy sections satisfy which framework controls: SOC 2 CC6.7 and CC6.8; ISO 27001 Control 8.1; HIPAA §164.310(d); GDPR Article 32. Align this mapping with your remote access policy to avoid overlapping or contradictory controls.

9. Set a review reminder. Annual review, plus the trigger conditions listed in the policy itself. Put it in the calendar now.

How to Develop a BYOD Security Policy Step by Step

The most common question I get from founders going through SOC 2 readiness: “How do I develop a byod security policy without it turning into a bureaucratic mess?” For a thorough technical reference, NIST SP 1800-22 covers mobile device security in depth, including BYOD architectures.

Keep it proportionate to your risk. For a 15-person startup with no PHI and no high-classification data, the policy can be two pages, MDM can be Google Workspace basic, and the goal is to have something documented and acknowledged before the audit window opens.

For a 100-person company processing customer financial data, you need proper MDM, conditional access, a real exception process, and quarterly checks on enrollment status.

Scale the policy to match your actual risk.

BYOD Policy Best Practices Checklist

Before publishing, verify:

• MDM tool selected and tested on representative iOS and Android devices
• Work-profile or user-enrollment mode confirmed as the deployment model (not full supervision)
• Privacy section reviewed by legal if operating in GDPR jurisdictions
• Employee communication written in plain English, no technical jargon
• Reimbursement approach cleared with payroll for tax treatment
• Offboarding procedure documented and added to the HR departure checklist
• Acknowledgement process defined: how employees sign, where records are stored
• Compliance control mapping documented for SOC 2 / ISO 27001

BYOD Policy and Compliance: SOC 2, ISO 27001, HIPAA, and GDPR

If you’re asking whether you need a BYOD policy for compliance purposes, the honest answer is yes, across all four frameworks. Here’s the mapping.

SOC 2 and Your BYOD Policy

SOC 2 CC6.7 is the control that trips most companies up. It requires controls over the transmission and movement of data, which includes personal devices used to access in-scope systems.

Auditors will ask for: the BYOD policy document (approved and versioned), MDM enrollment records, a compliance status report showing enrolled devices meet security requirements, and employee acknowledgement records.

The most common finding isn’t that companies have no policy. It’s that the policy says “devices must be enrolled in MDM” but there’s no evidence that any MDM is actually deployed. The document and the implementation must align.

ISO 27001: Mobile Device Policy Requirements

ISO 27001:2022 Control 8.1 is explicit. It requires a mobile device policy that covers authorised device types, required security measures, use of personal devices for work, and procedures for loss or theft.

During certification audits, assessors look for evidence the policy was communicated, acknowledged by employees, and enforced. Having the document is necessary but not sufficient.

HIPAA: Protecting PHI on Personal Devices

HIPAA doesn’t ban BYOD. It requires that the risks be identified and mitigated. The HIPAA Security Rule Risk Analysis must include personal devices as a documented threat vector. If PHI can be accessed from personal devices, you need documented access controls, encryption, remote wipe capability, and audit logging. Device access events should fall within the scope of your logging and monitoring policy.

If your MDM vendor processes PHI in order to manage devices (for example, if it logs which PHI-accessible apps are installed), you may need a Business Associate Agreement with that vendor.

GDPR: Personal Data and BYOD Policy Obligations

GDPR adds an employee-side privacy obligation that doesn’t exist in the other frameworks. GDPR Article 13/14 requires you to inform employees what personal data is processed, why, and how, before MDM is deployed on their personal devices. If MDM on employee personal devices processes any personal data (device identifiers, location, app inventory), you have obligations under Article 13/14 to inform employees what is being processed, why, and how.

The privacy section in the policy document serves this purpose. Make it clear, include it in what employees sign, and have legal review it before deployment.

What Evidence Does an Auditor Want to See?

I’ve reviewed a lot of BYOD compliance packages. The ones that pass consistently have the same eight things. The ones that fail are usually missing two or three of them.

The hardest one for most companies is the offboarding records. Access gets revoked in Okta or Google Workspace, but nobody documents whether the MDM wipe was completed. Build that step into the HR departure checklist and treat it the same as any other access revocation.

Seven Mistakes That Undermine a BYOD Programme

These are the mistakes I see most often. Some are obvious in retrospect; others survive multiple internal reviews before they surface in an audit.

1. Writing a policy nobody can find. The policy exists, but it’s buried in a Google Drive folder nobody knows about. Auditors ask for evidence the policy was communicated. “It’s somewhere in Drive” is not that evidence.

2. No MDM despite the policy requiring it. The single most common gap: the policy says devices must be enrolled in MDM, but no MDM is deployed. The policy is aspirational fiction. Auditors will notice, and it will be a finding.

3. Full device wipe authority without upfront employee consent. Claiming the right to remotely wipe personal devices without getting explicit prior consent creates legal and HR liability. Use work-profile containerisation (which only wipes company data) or get written consent for full wipe authority before employees enrol.

4. No acknowledgement process. Employees can’t be held to a policy they weren’t formally told about and didn’t sign. Acknowledgement records are evidence, not HR paperwork.

5. Contractors and third parties left out of scope. External consultants with access to internal systems are as much a BYOD risk as employees. A policy that only covers employees leaves a visible gap.

6. No offboarding process for personal devices. System access gets revoked in Okta. The MDM wipe of the work profile? Nobody checks. Company data persists on former employees’ personal devices for months. Build the MDM wipe step into the offboarding checklist and keep a record that it was completed.

7. Policy not updated when the MDM tool changes. You switched from one MDM platform to another. The policy still names the old one. Auditors find the mismatch. Always update the policy when named tools change.

BYOD Policy for Startups, SMBs, and Enterprise

Startups: A Lightweight BYOD Policy That Works

I’ll say this plainly: a startup does not need a thirty-page BYOD policy. What you need is a document that exists, is approved, is acknowledged, and has evidence of enforcement.

For a seed or Series A company: two pages is enough. Google Workspace MDM or Microsoft Intune basic covers iOS, Android, and Windows, and both are often free with existing licenses. Work-profile enrollment on Android and user-enrollment on iOS gives you remote wipe, compliance checks, and MDM management without full device supervision.

Get every employee and contractor to sign an acknowledgement before they access company systems from a personal device. The bar for early-stage is: “we have a policy, we deployed MDM, here are the enrollment records, here are the signed acknowledgements.” That clears SOC 2 CC6.7 at a Type 1 level.

Growing Companies: Scaling Your BYOD Security Programme

At 20-200 employees, the informal setup starts to break down. You have people on different device types, different OS versions, and different roles with different data access levels.

This is the point to move to a dedicated MDM tool (Jamf or Kandji for Apple-first companies; Intune for Windows and Android environments). Separate the byod company policy from the company-owned device policy: they have different security requirements and different offboarding procedures. Introduce conditional access: devices that are not enrolled and compliant are blocked from email and SaaS tools at the identity provider level.

Begin systematic evidence collection: quarterly MDM compliance reports, annual policy review with documented sign-off, enrollment records exported and stored alongside your other audit evidence.

Enterprise and Regulated Industries: BYOD Policy Restrictions

At scale, or in regulated industries, BYOD tends to get restricted rather than expanded.

Common patterns: BYOD is permitted for general productivity tools (email, calendar, messaging) only, with high-sensitivity data requiring a company-managed device. A corporate byod policy at this stage references data classification tiers explicitly: personal devices can access tier 1 (public) and tier 2 (internal) data; tier 3 (confidential) and above require a managed device.

Healthcare enterprise adds a HIPAA-specific addendum covering PHI access tiers, audit log requirements, and device encryption verification. Finance and legal roles often move to COBO (corporate-owned, business only) for anyone handling regulated data, with a lighter BYOD policy for general staff.

The principle is simple: the more sensitive the data, the more controlled the device model.

Managing Your BYOD Policy with ComplyJet

Writing the policy is one task. The administrative work around it, collecting signatures, tracking MDM enrollment, mapping controls, maintaining evidence, scheduling reviews, can easily take more ongoing effort than the initial draft.

ComplyJet handles this:

• Policy templates: a BYOD policy template you can adopt, edit, and publish directly from the platform
• Employee acknowledgements: built-in signature workflow; every sign-off is logged with name, date, and policy version; full acknowledgement history is available for auditors
• Control mapping: the BYOD policy maps to SOC 2 CC6.7, CC6.8, CC6.1 and ISO 27001 Control 8.1 automatically; linkages update when you edit the policy
• Evidence collection: MDM compliance screenshots, acknowledgement logs, and review records are stored and tagged to the relevant audit
• Review reminders: ComplyJet sends a calendar-triggered notification when the policy is due for review; the review workflow captures who reviewed, what changed, and who approved

Whether you’re building your first byod policy or tightening your byod security policy ahead of a certification audit, the admin doesn’t have to live in a spreadsheet.

BYOD Policy FAQs

What Is a BYOD Policy?

A BYOD policy is a document that governs how employees and contractors use personally-owned devices, including phones, laptops, and tablets, to access company data and systems. It defines which devices are permitted, the required security settings, acceptable use rules, and what happens when a device is lost or an employee leaves.

What Should a BYOD Policy Include?

Every BYOD policy should cover: device eligibility and enrollment requirements, minimum security controls (MDM, PIN, encryption), acceptable use rules, data handling and privacy boundaries, reimbursement terms, incident response steps for device loss or theft, offboarding procedures, enforcement, an exception process, and an annual review cadence.

How Do I Develop a BYOD Security Policy?

Start with an audit of current device use. Choose an MDM deployment model (work-profile containerisation is recommended for BYOD). Draft the policy using a template and customise for your company size and applicable frameworks. Get a legal review if operating in GDPR jurisdictions. Get leadership approval. Communicate to employees with a clear explanation of what MDM can and cannot see. Collect acknowledgements. Run guided enrollment. Map to compliance controls. Schedule the annual review.

Which of the Following Is the Most Controlling BYOD Policy?

This is a standard IT governance exam question. The spectrum from least to most controlling is:

1. Blacklisting: blocks specific prohibited apps; minimal IT control otherwise
2. Whitelisting: only approved apps are permitted; more restrictive
3. Work-profile containerisation (MDM): separates and manages company data; IT controls the work partition only
4. Full MDM supervision with full device wipe: IT has visibility and control over the entire device; the most controlling option

The most controlling option is full MDM with full device wipe authority. In practice, this level of control is typically reserved for company-owned devices, not personal ones. For BYOD, work-profile containerisation (option 3) is both sufficient and more appropriate, because it balances security control with employee privacy.

Does SOC 2 Require a BYOD Policy?

SOC 2 doesn’t name a “BYOD policy” explicitly, but CC6.7 requires documented controls over the transmission and movement of data, including access from personal devices. If employees access in-scope systems from personal devices and you have no policy, this is a finding. It comes up in almost every first SOC 2 readiness assessment.

Does ISO 27001 Require a BYOD Policy?

Yes. ISO 27001:2022 Control 8.1 explicitly requires a mobile device policy covering the use of personally-owned devices to access organisational information. The 2013 equivalent is A.6.2.1. If you’re seeking ISO 27001 certification, you need this policy documented, communicated, and evidenced.

How Often Should a BYOD Policy Be Reviewed?

Annually at minimum. Also review when you change MDM tools, add a new compliance framework, have a device-related security incident, or make significant changes to remote or hybrid working arrangements.

What Is the Difference Between BYOD and COPE?

BYOD: the employee owns the device and chooses it; the company sets security requirements. COPE (Corporate-Owned, Personally Enabled): the company purchases the device; the employee may use it for personal purposes; the company retains full MDM supervision rights. COPE gives IT more control and eliminates most of the employee privacy considerations that complicate BYOD. It’s more expensive because the company buys the hardware.

Policies to Read Alongside This One

A BYOD policy doesn’t exist in isolation. These related policies work in concert with it:

• Remote Access Policy: governs how employees connect to internal systems from any location and any device, including personal ones. BYOD and remote access controls often overlap; ensure they’re consistent with each other.
• Remote Working Security Policy: broader controls for employees working outside the office, covering physical security at home, home network requirements, and screen privacy. Complements BYOD with the environmental security side.
• Asset Management Policy: how company and registered personal devices are tracked in the asset inventory. Enrolled BYOD devices should appear in the asset register with their compliance status.
• Data Classification Policy: defines sensitivity tiers for company data. The BYOD policy references these tiers to determine which data can be accessed from personal devices and which requires a managed device.
• Identity and Access Management Policy: authentication and access controls that apply regardless of device type. Conditional access policies tie device compliance to IAM, connecting the two policies in practice.
• Network Security Policy: network segmentation and Wi-Fi rules. Personal devices on corporate networks should sit on a separate VLAN or guest segment, not on the same network as production systems.