How to Create Custom Compliance Rules in AirWatch

AirWatch, now commonly associated with VMware Workspace ONE UEM, gives IT teams a central way to configure, monitor and secure business endpoints. Custom compliance rules help translate an organisation’s security standards into automated checks, so access decisions are based on device condition rather than guesswork.

A compliance policy can check operating system versions, encryption, passcode settings, compromised status, required applications and other controls. When a device falls outside the policy, AirWatch can notify the user, require remediation, block access or initiate a more serious action such as an enterprise wipe.

The most effective policy design starts with a clear business risk. A rule for an executive’s iPhone may need a different exception process from a shared Android tablet used in a Melbourne warehouse. Likewise, a corporate Windows laptop in Sydney may require stronger controls than a personally owned device enrolled for email access.

Australian organisations also need to consider the Privacy Act 1988, the Australian Privacy Principles and the Notifiable Data Breaches scheme. A well-designed policy supports these obligations by reducing exposure, while avoiding excessive collection of personal information from employees using their own devices.

Define the compliance outcome first

Before opening the Workspace ONE UEM console, document what “compliant” means for each device group. Separate mandatory controls from preferred settings, and decide which failures create a genuine security risk. Encryption and an unsupported operating system may justify access restriction, while an outdated optional application may only require a reminder.

Use plain operational language for each rule. For example, “corporate Windows devices must run a supported version with BitLocker enabled” is easier to implement and audit than “maintain appropriate endpoint security”. This wording also helps service desk staff explain decisions when an employee in Brisbane or Perth receives a remediation message.

Create device categories before creating policies. Common categories include corporate-owned, employee-owned, shared-use, ruggedised and kiosk devices. Add ownership type, operating system, business unit and risk level to smart groups so rules can be assigned with precision instead of applying one broad policy to every enrolment.

Open the right policy area

In the AirWatch or Workspace ONE UEM console, compliance controls are generally managed from the Devices area under Compliance Policies. Menu names can differ between cloud releases, console roles and older AirWatch deployments, so administrators should use the console search function or current VMware documentation if the location is different.

Start by selecting the platform and device ownership scope. Choose the relevant operating systems, then add rules from the available conditions. Typical checks include minimum operating system version, passcode complexity, encryption status, compromised or jailbroken status, prohibited applications, required applications and device inactivity.

Give each policy a meaningful name, description and owner. Include the intended population and review date in the description. A useful naming pattern might be CORP-iOS-Baseline-AU or BYOD-Android-Access, which makes reporting and troubleshooting easier as the environment expands.

Add checks that match real risk

A custom rule should measure something AirWatch can reliably observe. For a corporate laptop, useful controls may include disk encryption, an approved endpoint protection agent, a supported Windows build and recent check-in activity. For iOS and Android, passcode settings, device integrity, minimum operating system versions and managed application presence are often more practical.

Avoid building a policy around information that is difficult to verify or unnecessary for the security decision. Monitoring an employee’s complete application history can create privacy concerns under the Australian Privacy Principles, particularly in a bring-your-own-device programme. Check only what is needed to protect company data and communicate the purpose clearly.

Custom attributes, sensors or scripts may be appropriate when the standard compliance conditions do not cover a business requirement. For example, a script could verify a configuration value on a managed Windows device. Test such extensions carefully because a failed script, changed operating system permission or altered output format can mark a large device population as non-compliant.

Configure actions and remediation

A rule is incomplete until its response is defined. AirWatch can usually send a notification, require the user to correct the issue, escalate after a grace period, block access to managed resources or perform an enterprise wipe. The appropriate response depends on the sensitivity of the data and whether the device is corporate-owned or personally owned.

Use graduated enforcement for ordinary failures. A user might receive an initial message, followed by a second reminder after 24 hours and restricted access after 72 hours. A lost, compromised or deliberately tampered device may require immediate action. The policy should state what the user must do, where to get help and when access will be restored.

For BYOD users, avoid destructive actions unless the enrolment agreement and privacy notice clearly support them. Removing managed applications and corporate profiles is generally more proportionate than wiping a personally owned phone. This distinction matters for employees working from home in Adelaide or travelling between regional sites with a personal handset.

Test exceptions before enforcement

Pilot a new policy with a small smart group containing representative devices. Include current iPhones and Android phones, Windows laptops, older hardware, devices on mobile data and users with different enrolment types. Check that the rule evaluates correctly and that the user-facing message explains the required fix.

Test failure and recovery paths separately. Disable encryption on a test laptop, install a prohibited application, change a passcode setting or use an unsupported operating system version. Confirm that the expected event appears in the console, the correct notification is delivered and access is restored after remediation.

Before expanding the policy, record false positives and valid exceptions. A construction tablet may need a different update window because it operates in remote Queensland, while a warehouse scanner may not support the same controls as an office laptop. Use separate smart groups or documented exclusions rather than weakening the baseline for everyone.

Review the policy in an Australian context

Australian businesses often manage a geographically spread workforce, from offices in Sydney and Melbourne to mining, logistics and field-service operations outside major cities. Connectivity can be intermittent, devices may be shared across shifts, and support teams may work across Australian Eastern, Central and Western time zones. Compliance grace periods should reflect those operating conditions.

Privacy and security requirements should be reviewed together. The Australian Privacy Principles encourage responsible handling of personal information, while the Notifiable Data Breaches scheme makes serious data exposure an incident-management concern. A compliance policy should therefore limit data collection, protect administrative access and preserve useful audit records without retaining irrelevant personal details.

Local procurement and support realities matter as well. Some organisations use a mixture of Apple, Samsung, Windows and specialist rugged devices because the Australian endpoint market is diverse. Teams comparing management approaches can also consult endpoint guidance when assessing how device governance fits into a broader security programme.

Compare policy choices before publishing

The following model helps administrators select a proportionate response. It is a starting point rather than a fixed AirWatch configuration, because available actions depend on platform, licensing, integrations and console version.

Device or situation Useful compliance checks Suitable first response Escalated response
Corporate Windows laptop Encryption, supported build, endpoint protection, recent check-in Notify and provide remediation steps Restrict access or enterprise wipe
Corporate iPhone or iPad Passcode, iOS version, device integrity, managed apps Prompt the user to update or correct settings Block managed access
Employee-owned Android phone Work profile, encryption, minimum version, screen lock Notify and quarantine work data Remove work profile
Shared warehouse or field tablet Kiosk configuration, approved apps, check-in status Alert local support and retry after a grace period Restrict the device from shared resources
High-risk or compromised endpoint Integrity status, suspicious state, missing security controls Immediate access restriction Incident response and selective wipe

A strong policy also includes ownership for ongoing review. Assign an administrator or security team to check rule performance monthly, with a formal review after operating system releases, major application changes or an incident. Track how often each rule triggers, how many failures are false positives and how long users take to remediate.

Operational checks for a clean rollout

Signals that deserve a policy review

Move from a rule to a managed control

Custom compliance rules work best when they are connected to enrolment, application management, identity access and incident response. A rule that detects an outdated operating system is useful, but its value increases when the user receives a clear fix, the service desk can see the reason and access controls respond consistently.

Keep the first version small and measurable. Start with controls that protect company data, validate them with a pilot group and increase enforcement gradually. Document exceptions for accessibility, operational requirements and approved legacy equipment rather than allowing informal bypasses.

Review the finished policy with security, privacy, HR and business representatives before making it mandatory. Then publish it through a controlled change process, monitor results and refine the rules as Australian privacy obligations, device platforms and workplace conditions change. Begin with a focused pilot in AirWatch and turn the results into a dependable endpoint compliance standard.