Policy, Procedure, Control

Mobile devices sit at the center of daily work, so weak rules create both security risk and support overload. In CompTIA A+ Core 2 (220-1202), Domain 2.0 (Operating Systems), Objective 2.8 (Mobile device connectivity and application support, with focus on policy, procedures, and control), you're expected to link technical actions to clear, enforceable rules. That means knowing not only what a feature does, but also when an organization should allow it, restrict it, or require it. In short, good policy, procedures, and control reduce data loss, speed up troubleshooting, and set user expectations.

This section breaks down the key controls you'll see on the exam, including locator apps, remote wipe, remote backup apps, and failed log-in attempt restrictions. It also explains how these tools support incident response, account recovery, and device replacement without guesswork.

You'll also review core policy topics that guide real-world decisions, such as MDM, BYOD vs. corporate-owned devices, and profile security requirements. By the end, you should be able to choose the right control for the risk and justify it in plain terms.

Mobile Policies Explained

For CompTIA A+ Core 2 (220-1202), Domain 2.0 (Operating Systems), Objective 2.8, you need to explain how an organization sets rules for phones and tablets, how staff carry them out, and how the device enforces them. On mobile endpoints, these ideas show up in everyday choices like screen locks, encryption, MDM enrollment, remote wipe, backup, and limits on failed sign-in attempts. The terms sound similar, but they answer different questions: What must be true (policy), how to make it true (procedure), and what keeps it true (control).

When you read a scenario, keep the order straight. First, find the rule the company cares about. Next, look for the steps a technician or user must follow. Finally, choose the safeguard that enforces or verifies the result.

Policy vs. procedure: rules compared to step-by-step actions

A policy is the rule. It states expectations and boundaries in plain language. A procedure is the step-by-step method used to follow that rule. On phones and tablets, this gap matters because users act quickly, devices roam, and small mistakes can expose accounts or data.

Policies usually come from management, security, or compliance needs. Procedures often come from IT operations because they must work in real life. The two should fit together. If the policy is strict but the procedure is vague, support tickets rise. If the procedure exists without a policy, staff may apply it inconsistently.

Here are common mobile examples that show the difference:

• Password length policy vs. reset procedure: A policy might require a 6-digit (or longer) passcode and a short auto-lock time. The procedure then explains how a user resets a forgotten passcode, how the help desk verifies identity, and when IT triggers account recovery or remote wipe after repeated failures.
• BYOD policy vs. enrollment steps: A policy may allow personal phones for email only if they meet profile security requirements (screen lock, encryption, up-to-date OS). The procedure then lists the exact enrollment steps in MDM, what permissions users must accept, and what happens if the device falls out of compliance.
• Data retention policy vs. backup steps: A policy might state how long business data must be retained and where it can be stored. The procedure then explains how to enable remote backup applications (or approved cloud backup), how often backups run, and how to restore data during device replacement.

Procedures also reduce variance. They help new technicians follow the same path as experienced staff. Just as important, written procedures support audits because you can show what you do, not only what you claim to do.

A practical test: if someone asks, "What's the rule?" you are in policy. If they ask, "What do I click next?" you are in procedure.

Controls: the guardrails that enforce the rules

A control is a safeguard that enforces a policy or supports a procedure. Controls can be technical (device settings, MDM rules, encryption) or administrative (training, approval workflows, access reviews). On mobile devices, controls matter because you often cannot rely on user judgment during loss, theft, or rushed work.

Common mobile controls you will see in both real environments and exam questions include:

• Passcode requirements: Minimum length, complexity, and auto-lock timers, often pushed through MDM.
• Biometrics: Fingerprint or facial recognition, usually paired with a passcode as a fallback.
• Encryption: Device encryption protects stored data if a phone is lost or stolen.
• App allow lists: Approved app lists reduce risk from unsafe or untested apps.
• Remote wipe: Clears data when a device is lost, stolen, or owned by a departing employee.
• Account lockouts and failed log-in attempt restrictions: Limits repeated guesses and slows brute force attempts.

Controls also fall into three simple types:

• Preventive controls stop a problem before it happens (for example, enforced passcodes or app allow lists).
• Detective controls reveal that a problem happened or is happening (for example, MDM compliance alerts or sign-in logs).
• Corrective controls reduce harm after an event (for example, remote wipe or restoring data from remote backup applications).

In practice, organizations combine them. A BYOD policy might require encryption (preventive), MDM reporting (detective), and remote wipe for lost devices (corrective). This layered approach matters because mobile threats vary. Loss and theft happen often, but misuse and misconfigurations cause damage too.

Controls should match the risk. Strong controls on high-value data are normal, even if they add friction.

Why exam questions focus on risk, not brand names

In A+ Core 2 (220-1202), mobile questions usually test outcomes, not vendor labels. You are expected to pick the action that best protects data, confirms identity, or supports users during common events like device loss, account lockout, or device replacement. As a result, brand names and specific menus matter less than the security goal.

A reliable way to read mobile scenarios is to sort the facts into three buckets:

1. Identify the asset: What needs protection, the device, the account, or the data (emails, files, saved app tokens)?
2. Name the threat: Is it loss, theft, misuse, or simple user error (forgotten passcode, repeated failed sign-ins)?
3. Pick the best control: Choose the control that most directly reduces the risk, while still fitting the situation.

This approach also helps when multiple answers look reasonable. For example, if the scenario says a phone is missing and contains corporate email, remote wipe directly protects data. If the scenario stresses device replacement after damage, remote backup applications and restore steps fit better. If the user keeps failing sign-ins, failed log-in attempt restrictions and account recovery procedures address the real issue.

When questions mention BYOD or corporate-owned devices, adjust your choice. Corporate-owned phones usually justify stricter controls (full-device management, wider wipe authority). BYOD often uses narrower options (managed profiles, selective wipe), because the user owns the device.

In short, focus on what the organization must prevent, detect, or fix. Once you think in risks and outcomes, the right answer becomes easier to justify.

MDM Basics

For CompTIA A+ Core 2 (220-1202), Domain 2.0 (Operating Systems), Objective 2.8, you need to understand Mobile Device Management (MDM) as a practical set of controls, not a brand name. MDM connects mobile policy to real enforcement, so IT can set required security settings, confirm compliance, and respond quickly when risk changes. In other words, MDM turns written rules into device behavior that stays consistent across phones and tablets.

Just as important, MDM draws boundaries. It can protect company data without turning a personal phone into a fully monitored endpoint, but only if the organization chooses the right management model and documents it clearly.

A simple mental model helps: policy states the rule, MDM applies the rule, and compliance checks whether the rule still holds.

What MDM can manage, from settings to apps to data

MDM platforms focus on a few core capability areas, and these show up often in Core 2 scenarios. The details vary by operating system and ownership model (BYOD vs. corporate-owned), but the goals stay the same: reduce risk, reduce support time, and keep access predictable.

Here are key MDM capabilities you should recognize:

• Push Wi-Fi, VPN, and email settings: IT can send approved SSIDs, VPN profiles, and mail configurations to devices. This reduces setup errors and prevents users from selecting unsafe networks or weak VPN options.
• Enforce screen lock rules: MDM can require a passcode, set minimum length, and set an auto-lock timer. This supports policies tied to lost devices and unattended phones.
• Require device encryption: Encryption protects data at rest. If a device is stolen, encryption reduces the chance that stored emails, files, or app data can be read.
• Manage certificates: MDM can install and renew certificates for Wi-Fi, VPN, or email. Certificates reduce password reuse and support stronger authentication.
• Deploy and update apps: IT can publish approved apps, push updates, and remove apps that are no longer allowed. This helps standardize tools and reduce unpatched software.
• Block risky apps: Depending on the platform, MDM can restrict apps by name, category, or store access. The goal is to reduce malware exposure and prevent data from flowing into unapproved apps.
• Separate work and personal data (when supported): Many platforms support managed containers or work profiles. This allows selective wipe of business data while leaving personal photos and messages intact.
• Gather inventory: MDM can report device model, OS version, serial identifiers, and installed managed apps. Inventory supports audits, troubleshooting, and replacement planning.

MDM also has privacy boundaries, and you should expect policies to state them. On BYOD, organizations often limit collection to work-related data and device posture (for example, OS version and compliance state). Content such as personal photos, personal messages, and personal browsing history should not be collected unless the policy and law allow it, and the user has clear notice.

Enrollment, profiles, and compliance checks

Enrollment is the process of joining a device to management. Until a device enrolls, IT cannot reliably apply settings, confirm security posture, or respond to loss with consistent actions. In exam terms, enrollment is often the turning point between a device that is merely "used for work" and a device that is controlled under policy.

After enrollment, MDM uses two building blocks that you should keep distinct:

• A configuration profile is a package of settings. For example, it might define Wi-Fi, VPN, email, certificate payloads, and restrictions (such as blocking unknown app sources where applicable).
• A compliance policy is the rule set that determines whether the device is acceptable. For example, it may require encryption, a screen lock, a supported OS version, and no high-risk status such as jailbreak or root access (where detectable).

Compliance checks run on a schedule or after key changes. When a device fails, the response should follow policy and be predictable for users. Common outcomes include:

1. User warnings and grace periods: The user receives a prompt to enable encryption, set a passcode, or update the OS. A grace period reduces support load while still setting a clear deadline.
2. Limited access: The system can restrict access to corporate email, VPN, or specific apps until the device returns to compliance. This limits exposure while avoiding immediate data loss.
3. Quarantine or blocking: High-risk devices may be blocked from connecting to company services. This is common when the device is outdated, compromised, or repeatedly noncompliant.

These steps protect company systems because mobile access is a direct path to sensitive data. If a device lacks a lock screen or runs an outdated OS, an attacker may gain access without needing to break the corporate network first.

Compliance is less about punishment and more about reducing preventable exposure, especially for email, VPN, and cloud storage.

Offboarding and device lifecycle control

Offboarding is where policy, procedure, and control must align. When a user changes roles or leaves, delays create risk. At the same time, rushed actions can destroy business data that still needs to be retained. Good lifecycle control balances speed with documentation.

When roles change or employment ends, IT should follow a clear sequence:

1. Remove access first: Disable or revoke account access (email, VPN, single sign-on, and app access) before taking device actions. This blocks continued access from other devices too.
2. Rotate credentials and revoke tokens: Change shared secrets, rotate service account credentials when relevant, and revoke active sessions. Token revocation matters because many apps stay signed in for weeks.
3. Remove or update profiles: For a role change, push new profiles and remove old ones. For separation, remove management profiles based on ownership and policy.
4. Wipe work data (selective wipe when possible): On BYOD, selective wipe protects the company while respecting personal ownership. On corporate-owned devices, a full wipe may be required to prepare the device for reassignment.
5. Document actions and timing: Record what was removed, when it happened, and who approved it.