BYOD Policy Templateand Security Guide

What Is a BYOD Policy?

A BYOD policy (bring your own device policy) is a written set of rules that governs how employees and contractors may use personally owned phones, tablets, and laptops to access company systems, email, and data. It defines who is eligible, what security configuration the device must meet, which company data may live on it, what the organization can and cannot see or control, and what happens when the device is lost, the employee leaves, or the rules are broken. A BYOD security policy is the same document with the emphasis on the technical and procedural safeguards rather than the HR convenience side.

For an unregulated business, a weak BYOD policy is an annoyance. For a defense contractor handling controlled unclassified information (CUI), a medical practice handling protected health information (PHI), a SOC 2 service organization, or a merchant with a cardholder data environment, it is a compliance finding waiting to happen. Every one of those frameworks expects you to know which devices touch regulated data, to encrypt that data, to control the connection of mobile devices, and to be able to remove the data when the relationship ends. A personal phone that reads company email with no policy and no management is a device you cannot inventory, cannot wipe, and cannot defend to an assessor.

This page is for the business owner, office manager, compliance lead, or IT director at a small or mid-size regulated organization who needs a usable BYOD policy template now, needs to understand what each section is for, and wants to know how to enforce it with technology rather than hope. Petronella Technology Group has served clients in Raleigh, Durham, Cary, Chapel Hill, and across North Carolina since 2002, and the template below is the same structure we start from in client engagements.

What a BYOD Policy Must Cover

Most BYOD policy examples you will find online are two pages of HR language that say "use good judgment" and "the company may monitor your device." Neither statement is enforceable, and neither gives an assessor anything to test. A policy that works for a regulated business needs the 12 sections below, each stating something specific that a technician can configure and an auditor can verify.

Free BYOD Policy Template

The template below is written to be adopted. Replace every bracketed placeholder, delete any section that genuinely does not apply, and have your employment counsel review sections 8, 9, 10, and 12 before you publish, because state law on employee privacy and personal property varies. If you handle CUI, read the framework section that follows before adopting section 7 as written, since the honest answer for most defense contractors is to narrow BYOD to email and calendar in a managed container, or to prohibit it entirely in favor of company-owned devices.

1. Purpose

[Company Name] permits eligible workforce members to use personally owned mobile devices for limited business purposes under the conditions set out in this Bring Your Own Device (BYOD) Policy. The purpose of this policy is to protect the confidentiality, integrity, and availability of [Company Name] information and systems, to meet [Company Name]'s obligations under [applicable frameworks, for example NIST SP 800-171 and CMMC 2.0, the HIPAA Security Rule, SOC 2, PCI DSS], and to make clear to each participant what [Company Name] may and may not do with respect to a personal device that accesses company resources.

2. Scope

This policy applies to all employees, contractors, interns, temporary staff, and other workforce members of [Company Name] who use, or request to use, a personally owned smartphone, tablet, laptop, or wearable device to access any [Company Name] system, application, network, email account, messaging platform, or data. It applies regardless of the device's location, ownership of the cellular or internet service, or whether the device is used during or outside working hours. Devices owned, leased, or issued by [Company Name] are governed by the [Company Name] Mobile Device Policy and the [Company Name] Acceptable Use Policy rather than by this document. Where this policy is more restrictive than another [Company Name] policy, this policy governs for personal devices.

3. Definitions

For the purposes of this policy, the following terms have the following meanings. "Personal Device" means any computing device owned by a workforce member rather than by [Company Name]. "Company Data" means any information created, received, stored, or transmitted in the course of [Company Name] business, including email, messages, documents, contacts, calendar entries, and credentials, regardless of where it is stored. "Regulated Data" means Company Data subject to a legal or contractual protection requirement, including controlled unclassified information (CUI), protected health information (PHI), cardholder data, and any data classified as Confidential or Restricted under the [Company Name] Data Classification Policy. "Work Profile" or "Container" means the managed, encrypted, logically separated area on a Personal Device created by [Company Name]'s mobile device management (MDM) or mobile application management (MAM) platform, within which Company Data is stored and company applications run. "Selective Wipe" means the removal of the Work Profile, company applications, and Company Data from a Personal Device without removing personal applications, photos, messages, or other personal content. "Full Wipe" means the reset of a device to factory condition, which removes all content. "Compromised Device" means a device that has been jailbroken, rooted, infected with malware, accessed by an unauthorized person, or otherwise placed in a state where [Company Name] cannot rely on its security controls.

4. Eligibility and Enrollment

Participation in the BYOD program is a privilege, not a right, and may be denied or revoked at [Company Name]'s discretion. A workforce member must obtain written approval from their manager and from [IT Contact] before any Personal Device is connected to [Company Name] resources. Roles that require routine access to Regulated Data may be excluded from the BYOD program and issued company-owned devices instead; [IT Contact] maintains the list of excluded roles. Before access is granted, the workforce member must complete the following steps: sign the acknowledgment at the end of this policy; complete [Company Name] security awareness training, including the mobile device module; enroll the device in [Company Name]'s MDM or MAM platform and accept the Work Profile; confirm the device meets every requirement in Section 6; and record the device make, model, operating system version, and serial or IMEI number with [IT Contact] for inclusion in the [Company Name] asset inventory. Access to [Company Name] email, applications, or data may not be configured on a Personal Device by any means other than the approved enrollment process. Configuring company email through a native mail application outside the Work Profile is prohibited.

5. Acceptable Use

Workforce members must use Personal Devices in a manner consistent with the [Company Name] Acceptable Use Policy, the [Company Name] Data Classification Policy, and the [Company Name] AI Acceptable Use Policy. Workforce members must not use a Personal Device to access, store, or transmit Company Data that the Work Profile has not been approved for. Workforce members must not share the device, its passcode, or any [Company Name] credential with any other person, including family members. Workforce members must not forward Company Data to personal email accounts, personal cloud storage, personal messaging applications, or personal artificial intelligence tools. Workforce members must not take screenshots or photographs of Regulated Data displayed on the device. Workforce members must not connect the device to [Company Name] internal networks other than the designated guest or BYOD network segment. Workforce members must keep the device in their physical control or secured when not in use, and must not leave an unlocked device unattended in a public place or vehicle. Workforce members must report any suspected security incident involving the device in accordance with Section 9.

6. Security Requirements for Personal Devices

A Personal Device must meet all of the following requirements at the time of enrollment and continuously thereafter; the MDM platform will evaluate compliance and may block access automatically when a requirement is not met. The device must run a manufacturer-supported operating system version listed on the [Company Name] supported platforms list maintained by [IT Contact], and must install operating system security updates within [number] days of release. The device must have full-device encryption enabled. The device must be protected by a passcode of at least [number] characters, or by biometric authentication backed by such a passcode, and must lock automatically after no more than [number] minutes of inactivity. The device must not be jailbroken, rooted, or running a modified operating system, and must not have developer or sideloading options enabled unless approved in writing by [IT Contact]. The device must have the [Company Name] MDM or MAM agent installed and must remain enrolled; removing the agent or the Work Profile terminates access immediately. Where [Company Name] requires it and the platform supports it, the device must run the [Company Name] approved mobile threat defense or endpoint detection agent. The device must have remote locate, lock, and wipe capability enabled for the Work Profile. The device must have automatic cloud backup of the Work Profile disabled, so that Company Data is not copied to a personal backup service. Access to [Company Name] resources from the device must use multi-factor authentication through [Company Name]'s identity platform. [Company Name] may update these requirements at any time; workforce members will be notified of material changes and must comply within the period stated in the notice.

7. Company Data on Personal Devices

All Company Data on a Personal Device must reside within the Work Profile. Company applications must be installed from the [Company Name] managed application catalog, and only applications listed in that catalog may be used to access Company Data. The following applications and storage locations are prohibited for Company Data: personal email accounts, personal cloud storage and file synchronization services, personal note-taking and messaging applications, personal artificial intelligence assistants, unmanaged browsers, removable storage, and any application outside the Work Profile. Copy, paste, share, save-as, and print actions from the Work Profile to personal applications are disabled by policy and must not be circumvented. The following classes of Regulated Data may never be stored on a Personal Device in any form, including within the Work Profile, unless [Company Name] has documented a specific exception approved by [Compliance Contact]: [list, for example controlled unclassified information, export-controlled technical data, cardholder data, and any data class designated Restricted]. Where [Company Name] handles CUI, the default position of this policy is that CUI is accessed only on company-owned, company-managed devices, and that Personal Devices are limited to email, calendar, and collaboration functions that have been configured to exclude CUI. Where [Company Name] handles PHI, PHI may be accessed within the Work Profile only through applications approved by [Compliance Contact], and must never be stored in local photos, downloads, or personal messaging. Company Data stored in the Work Profile remains the property of [Company Name] at all times.

8. Privacy and Monitoring

[Company Name] respects the privacy of workforce members and limits its visibility and control to the Work Profile and to the compliance state of the device. Through the MDM or MAM platform, [Company Name] can see: the device make, model, operating system version, and serial or IMEI number; whether the device is encrypted, passcode protected, and compliant with Section 6; whether the device is jailbroken or rooted; the list of company applications installed in the Work Profile; the approximate location of the device only when a lost-device action has been initiated under Section 9, where the platform supports it; and the contents of Company Data within the Work Profile, which [Company Name] may access for security, legal, and business continuity reasons. [Company Name] cannot see, and will not attempt to access: personal email, personal messages, personal photos and videos, personal browsing history, personal application data, personal contacts outside the Work Profile, call logs, or the device's location outside of a lost-device action. [Company Name] can perform the following actions on the device: enforce passcode, encryption, and update requirements; install, update, and remove applications inside the Work Profile; lock the Work Profile; and perform a Selective Wipe of the Work Profile. [Company Name] will not perform a Full Wipe of a Personal Device except where the workforce member requests it in writing, where the workforce member has not responded to a lost-device notification within [number] hours, or where [Company Name] is required to do so by law. Workforce members should be aware that Company Data within the Work Profile may be subject to legal hold, discovery, regulatory inquiry, or forensic examination, and that a Personal Device may need to be produced in connection with such matters.

9. Lost, Stolen, or Compromised Devices

A workforce member must report a lost, stolen, or suspected Compromised Device to [IT Contact] at [phone or email] immediately, and in no case later than [number] hours after discovering the loss or compromise, regardless of the day or time. The report must include the device identity, the approximate time and place of loss, and whether the device was locked at the time. Upon receiving a report, [Company Name] will attempt to locate and lock the Work Profile, will perform a Selective Wipe of the Work Profile, will revoke the device's access tokens and reset affected credentials, and will record the event in the [Company Name] incident log. If the device cannot be confirmed as recovered or wiped within [number] hours, [Company Name] may escalate the event to its incident response procedure and, where Regulated Data may have been exposed, will evaluate breach notification obligations under applicable law and contract. If a lost device is later recovered, the workforce member must present it to [IT Contact] for inspection before it is re-enrolled. A device that has been jailbroken, rooted, infected, or otherwise compromised will be removed from the program until [IT Contact] confirms it has been restored to a compliant state. Failure to report within the required window is a violation of this policy and may result in discipline, independent of any discipline related to the loss itself.

10. Separation and Device Retirement

When a workforce member's employment or engagement with [Company Name] ends for any reason, or when the workforce member changes to a role that is not eligible for BYOD, [Company Name] will perform a Selective Wipe of the Work Profile and revoke all access on or before the separation date, as part of the [Company Name] employee offboarding checklist. The workforce member must make the device available for Selective Wipe and must not attempt to retain, copy, forward, or export any Company Data before or after separation. If the workforce member replaces, sells, trades in, gives away, or otherwise disposes of an enrolled device, they must notify [IT Contact] in advance so that the Work Profile can be removed and the device record retired before the device leaves their control, and must enroll the replacement device through the standard process before accessing Company Data on it. Workforce members on an approved leave of absence may have Work Profile access suspended for the duration of the leave. [Company Name] will retain the enrollment and wipe records for each device for at least [retention period] to support audit and legal requirements.

11. Reimbursement and Support Boundaries

[Company Name] [does / does not] provide a stipend for business use of a Personal Device. Where a stipend is provided, it is [amount and frequency], is subject to [Company Name] expense policy, and does not transfer ownership of the device or any obligation for its upkeep to [Company Name]. The workforce member is responsible for the purchase, insurance, repair, replacement, and carrier service of the device. [Company Name] IT support, including the [Company Name] help desk, will assist only with: enrollment and un-enrollment; configuration of the Work Profile and company applications; troubleshooting access to [Company Name] systems; and Selective Wipe. [Company Name] will not support personal applications, personal accounts, hardware repair, operating system recovery, data recovery of personal content, or carrier issues. [Company Name] is not responsible for loss of personal data resulting from a Selective Wipe, a Full Wipe performed under Section 8, or any other action taken under this policy, and workforce members are responsible for backing up their personal content. Participation in the BYOD program does not entitle the workforce member to overtime or additional compensation for after-hours access unless required by applicable law or a separate written agreement.

12. Enforcement and Acknowledgment

Compliance with this policy is monitored through the MDM platform, periodic access reviews, and security audits. A device that falls out of compliance may be blocked from [Company Name] resources automatically until the condition is corrected. Violations of this policy may result in suspension or revocation of BYOD privileges, Selective Wipe of the Work Profile, and disciplinary action up to and including termination of employment or engagement, in accordance with [Company Name] disciplinary procedures. Where a violation also constitutes a breach of law or contract, [Company Name] may be obligated to report it to regulators, customers, or contracting officers. Exceptions to this policy may be granted only in writing by [IT Contact] and [Compliance Contact], must be documented with a business justification and compensating controls, and must be reviewed at least annually. This policy will be reviewed at least annually, and whenever there is a material change in [Company Name]'s regulatory obligations, device platforms, or management tooling. Questions about this policy should be directed to [IT Contact].

Employee Acknowledgment

I, [Employee Name], acknowledge that I have received, read, and understand the [Company Name] Bring Your Own Device Policy. I understand that participation in the BYOD program is voluntary and that I may withdraw at any time by requesting un-enrollment from [IT Contact]. I understand what [Company Name] can and cannot see and control on my Personal Device, as set out in Section 8. I consent to [Company Name] enrolling my device in its management platform, enforcing the security requirements in Section 6, and performing a Selective Wipe of the Work Profile at any time for the reasons stated in this policy, including upon my separation from [Company Name]. I understand that [Company Name] may perform a Full Wipe only in the circumstances described in Section 8, and that I am responsible for backing up my personal content. I agree to report a lost, stolen, or compromised device within the window stated in Section 9. I understand that violation of this policy may result in loss of access and disciplinary action.

Employee signature: ____________________ Date: __________
Printed name: ____________________ Device make, model, and serial or IMEI: ____________________
Approved by (manager): ____________________ Date: __________
Enrolled by (IT): ____________________ Date: __________

Store the signed acknowledgment with the employee's onboarding record, and attach the MDM enrollment confirmation. If you use ComplianceArmor®, the acknowledgment and enrollment record can be filed against the relevant control so an assessor can retrieve both in one place.

How to Customize the Template by Framework

The template above is deliberately framework-neutral. The table below shows which sections carry the weight for each framework our clients operate under, and what to tighten. The control identifiers are the ones assessors will reference when they ask to see your BYOD policy, so it is worth citing them in your policy or your system security plan.

The honest answer on BYOD and CUI

Defense contractors ask us about BYOD more than any other group, usually because a program manager wants to read contract email on their own phone. The short version: under NIST SP 800-171 and CMMC 2.0, nothing says "no personal devices," but 3.1.18 and 3.1.19 together require that any mobile device connecting to a system that processes CUI is controlled, inventoried, and encrypting CUI at rest. A personal phone in a managed container can technically meet that, but you then have to defend the container's boundary to a C3PAO assessor, keep the personal side out of scope, and be prepared for the device to be examined if there is an incident. Most of our clients in Raleigh and across North Carolina conclude that a company-owned, fully managed phone is cheaper in assessment effort than a personal phone in a container, and they limit BYOD to roles that never touch CUI. If you do allow a container for CUI, document it in your system security plan, state it explicitly in Section 7, and expect the assessor to ask for the MDM compliance report. The full control narrative is covered in Craig Petronella's CMMC 2.0 Certification Guide and on our CMMC compliance guide.

Medical practices in Durham, Chapel Hill, and Cary face a different calculation. HIPAA does not prohibit BYOD, and clinicians reading secure messages on personal phones is routine. The Security Rule simply expects you to have made the risk decision deliberately, to have the workstation use, device and media control, and encryption safeguards in place, and to be able to prove it. The template's Section 7 PHI language, plus MDM enforcement, is the usual path.

Petronella Technology Group is rated 4.7 across 92 verified TrustIndex reviews and 5.0 across 15 Google reviews.

BYOD Security Risks the Policy Has to Address

Each of the following risks maps to a section in the template. If your current policy does not speak to one of them, that is the section to rewrite first.

Unmanaged apps and shadow IT

On a personal device, the user installs whatever they like, and some of what they like will ask for access to contacts, photos, and files. A personal note-taking app that syncs to a personal cloud, a free PDF tool that uploads documents to a third-party server, or a consumer AI assistant that is handed a patient chart to "summarize" all move Company Data outside your control without anyone intending harm. The Work Profile and the managed application catalog in template Section 7 exist to make this structurally impossible rather than merely prohibited, and your AI acceptable use policy should be cross-referenced so the rules on AI tools are the same on every device.

Lost and stolen devices

Phones get left in rideshares, taken from gym lockers, and lifted from restaurant tables. If the device is encrypted, locked, and the Work Profile can be wiped remotely, a loss is an inconvenience. If any of those three is missing, a loss of a device holding PHI or CUI becomes an incident with a notification analysis attached. The reporting window in Section 9 matters because the organization cannot wipe what it does not know is gone, and because regulators and contracting officers measure your response from the moment of discovery.

Mixed personal and corporate data

Without a container, company email attachments land in the same downloads folder as personal files, company contacts merge into the personal address book, and a personal cloud backup quietly copies all of it. That mixing is what makes a departing employee's phone a data loss, what makes a Full Wipe a privacy dispute, and what makes a forensic examination of the device far more complicated. Containerization is the single most important technical control in a BYOD program, and it is what allows the privacy promises in Section 8 to be true.

Outdated operating systems and unpatched devices

A personal phone running an operating system the manufacturer no longer patches is a device with known, unfixable vulnerabilities reading your email. Company-owned devices get retired on a schedule through patch management; personal devices get retired when the owner feels like upgrading. Section 6 sets a supported-version floor and an update deadline, and the MDM compliance policy enforces it by blocking access from devices that fall behind.

Insecure networks

Personal devices live on home Wi-Fi, hotel Wi-Fi, coffee shop Wi-Fi, and whatever network the airport offers. The policy cannot control those networks, so it has to make the device safe regardless of the network: encrypted connections to company services through the identity platform, conditional access that evaluates device compliance on every sign-in, and no direct network-level VPN that drops an unmanaged device onto the internal LAN. This is the same reasoning behind our zero trust vs VPN guidance.

Phishing on mobile

Mobile screens truncate sender addresses, hide link destinations, and make the lock-screen preview of a text message look like a legitimate alert. Users click more on phones. Ongoing security awareness training with mobile-specific scenarios, multi-factor authentication that is resistant to push fatigue, and conditional access that blocks sign-ins from non-compliant devices all reduce the damage of a successful click. If you want to see how your workforce responds today, our free phishing security test is a reasonable starting measurement.

Departing employees keeping data

When someone leaves with company email, files, and contacts still on their personal phone, the organization has lost control of that data and often does not know it. Section 10 ties the Selective Wipe to the separation date and to the employee offboarding checklist, so the wipe is a scheduled task with an owner rather than something IT remembers a month later. The enrollment that happened during the employee onboarding checklist is what makes the wipe possible at all.

Forensic and legal hold complications

Craig Petronella is a North Carolina Licensed Digital Forensics Examiner (License 604180-DFE), and this is the risk that gets the least attention when a company adopts a permissive BYOD program. When an incident, a lawsuit, or a regulatory inquiry involves data on a personal device, the organization may need to preserve and examine that device. On a company-owned device, that is a routine tablet and mobile device forensics engagement. On a personal device, the examiner must separate the employee's personal content from company content, the employee may refuse to surrender the device, and the organization's legal position depends on what the policy and acknowledgment said in advance. Section 8 of the template puts the employee on notice that the Work Profile may be subject to legal hold and examination, and the container boundary gives the examiner a defensible scope. Without those two things, a digital forensics investigation of a BYOD device can stall before it starts, and that delay carries into your incident response timeline.

Enforcing the Policy: MDM, Containers, and Conditional Access

A BYOD policy is a set of promises about device state. Technology is how you keep them. The following controls are what we deploy for clients, and each one corresponds to a "must" statement in the template.

Mobile device management with a work profile

The MDM or mobile application management platform is the foundation. On Android, enrollment creates a work profile: a separate, encrypted, managed partition with its own applications and its own badge, which the organization controls and the employee's personal side cannot see into. On iOS and iPadOS, user enrollment and app protection policies achieve a similar separation, with managed applications and managed accounts kept distinct from personal ones. The platform enforces the Section 6 requirements (passcode, encryption, supported OS version, no jailbreak), installs the approved application catalog from Section 7, blocks copy and paste and save-as out of the managed apps, disables personal cloud backup of company data, and provides the Selective Wipe used in Sections 9 and 10. Petronella Technology Group's mobile device management service handles the platform configuration, the enrollment process, the compliance policies, and the ongoing device population management, so the policy's technical requirements are configured by someone who has done it before rather than interpreted by whoever is available.

Conditional access requiring a compliant device

Enrollment alone is not enough, because an enrolled device can drift out of compliance. Conditional access in the identity platform evaluates every sign-in and requires that the device be enrolled, compliant, and using multi-factor authentication before access to email, files, or applications is granted. A device that misses its update deadline, disables its passcode, or is detected as jailbroken loses access automatically until it is fixed. This is what makes the "may be blocked automatically" language in Section 12 true, and it is the control that satisfies the "control connection of mobile devices" requirement in NIST SP 800-171 3.1.18. For a periodic check that the device population and the people behind it still match what was approved, fold BYOD devices into your quarterly user access review.

Encryption, screen lock, and remote selective wipe

Modern phones encrypt by default once a passcode is set, which is why the passcode requirement does most of the work. The MDM compliance policy verifies encryption state and reports it, so you can produce an encryption report for every device touching PHI or CUI rather than assuming. Remote Selective Wipe removes the work profile, managed apps, and company accounts while leaving personal content alone, and the platform logs the action with a timestamp, which becomes your evidence for HIPAA device and media controls and for the offboarding record.

Endpoint detection and mobile threat defense where allowed

On personal laptops, if your policy permits them at all, the requirement should be the same endpoint detection and response agent and remote monitoring and management coverage as a company device, because a laptop with a full operating system is a much larger attack surface than a phone. Many organizations decide that personal laptops are out of scope for exactly this reason. On phones, a mobile threat defense agent can detect malicious apps, phishing links, and compromised network conditions and feed that state into conditional access. Where the device is enrolled in our program, those signals flow into the Managed XDR Suite and are watched by our 24/7 security operations center, so a compromised personal device is treated the same way as a compromised company endpoint: detected, isolated from company resources, and investigated.

Acknowledgment tracking and evidence

The signed acknowledgment, the enrollment record, the compliance reports, and the wipe logs are the artifacts an assessor asks for. ComplianceArmor®, Petronella Technology Group's compliance documentation platform, tracks policy acknowledgments by workforce member, files the BYOD policy against the relevant NIST SP 800-171, HIPAA, SOC 2, and PCI DSS controls, and keeps the evidence in one place that can be queried during an assessment rather than reconstructed from a ticket queue. The device records themselves live in IT asset management alongside company-owned hardware, and the policy, the supported platform list, and the enrollment runbook live in your IT documentation.

Common BYOD Policy Mistakes

These are the problems we find most often when a new client hands us their existing BYOD policy, and what we change.

Three Ways to Get a BYOD Policy: An Honest Comparison

You can write the policy yourself from the template above, you can buy a generic HR template, or you can have Petronella Technology Group write it and enforce it. All three produce a document. They differ in whether the document matches your framework, whether it matches your systems, and whether anyone is accountable for keeping the two aligned.

Our Approach to BYOD Policy and Enforcement

For clients who engage Petronella Technology Group to build the BYOD program rather than just the document, the work runs in six steps. The sequence matters: the policy is written after we know what devices exist and what data they touch, not before.

This page was written by Craig Petronella, MIT-certified cybersecurity professional, CMMC Registered Practitioner, and author of "How Hackers Can Crush Your Business" and "IT Buyers Guide", both available with his other titles on our books page. The approach reflects what we have learned managing devices for regulated clients, supported by our IT help desk for day-to-day enrollment and support. For a broader view of what a small or mid-size business should have in place this year, download the free 2026 SMB Cybersecurity Survival Guide.

Frequently Asked Questions

Written by Craig Petronella, CMMC Registered Practitioner and NC Licensed Digital Forensics Examiner (License 604180-DFE), founder of Petronella Technology Group, Inc. in Raleigh, North Carolina. The template references NIST SP 800-171 Rev. 2 and NIST SP 800-124 Rev. 2, Guidelines for Managing the Security of Mobile Devices in the Enterprise. Questions about this template can be sent to info@petronellatech.com or 919-348-4912.