# Mastering Compliance Policy Logic in Hexnode: AND vs. OR Criteria

 Hexnode compliance policies use multiple criteria to evaluate device posture. Admins can combine criteria using `AND` or `OR` logic. Choosing the right logic is critical because it determines whether a single violation or a combination of conditions marks a device non-compliant.

Executive Summary
-----------------

 Compliance policy logic dictates how Hexnode evaluates endpoint criteria. `AND` logic is restrictive because every selected condition must match to trigger a non-compliant state. `OR` logic is broader because any single matching violation flags the device immediately.

 As a rule of thumb, use **AND**  to define scope constraints and  **OR**  to define risk triggers. For example,  **Ownership is Corporate AND BitLocker is Disabled** isolates corporate Windows endpoints lacking encryption. Conversely,  **Jailbreak is Enabled OR MDM profile is Removed<**  flags an endpoint if either critical security breach occurs.

AND vs OR Logic Comparison
--------------------------

 Comparison of AND vs OR logic in Hexnode compliance policies.  **AND**  requires all conditions to match (best for scope narrowing), whereas  **OR**  triggers on any single matching condition (best for multi-threat risk detection).

AND and OR Logic ComparisonLogicMeaningBest UseExample`AND`All conditions must be true simultaneously.Narrowing policy evaluation to a specific group, platform, or state.  **Ownership**  is  **Corporate**  AND  **BitLocker**  is  **Disabled**  `OR`Any single condition being true triggers non-compliance.Flagging an endpoint when any independent security risk occurs.  **Jailbreak**  is ` <strong> Enabled </strong> OR ` <strong> MDM profile </strong> `  <p>is <strong> Removed </strong> /code></p>`Workflow: Build Compliance Logic
--------------------------------

1. Define the specific risk or posture state you want to detect.
2. Determine whether non-compliance requires all conditions to fail simultaneously (`AND`) or if a single condition failure is enough (`OR`).
3. Use `AND` when including in-rule scope criteria, such as device ownership or OS family.
4. Use `OR` when evaluating multiple independent security threats on the same fleet.
5. If you need to evaluate multiple `OR` risks for a specific group, scope the policy using **Targets & Assignments** rather than in-rule `AND` criteria.
6. Deploy the policy to a pilot test group and review non-compliance alerts to confirm accurate evaluation.

Example Compliance Logic Patterns
---------------------------------

 Common compliance logic implementation patterns across enterprise scenarios, explaining why AND or OR is selected for corporate encryption, iOS threat detection, BYOD app enforcement, and blocklisted application monitoring.

Example Compliance Logic PatternsUse CaseCriteriaWhy This Logic WorksCorporate Windows Encryption  **Ownership** is **Corporate**  AND **BitLocker** is **Disabled**Only corporate devices missing BitLocker are flagged, preventing false alerts on personal endpoints.High-Risk iOS Threat Detection **Jailbreak** is **Enabled** OR **MDM profile** is **Removed**Either compromise is severe enough on its own to warrant immediate non-compliant status.BYOD App Readiness **Ownership**  is  **Personal** AND  **Missing apps count  **>  0**** Ensures required enterprise apps are evaluated strictly on personal devices enrolled in BYOD programs.General App Compliance  **Missing apps count**  >  0  OR  **Blocklisted apps count**  >  0  Triggers non-compliance whether a required app is missing or an unauthorized app is installed.Troubleshooting Compliance Logic Issues
---------------------------------------

 Troubleshooting checklist for compliance logic issues in Hexnode UEM, detailing potential causes and fixes for over-reporting non-compliance, missed threat detections, and BYOD policy misconfigurations.

Compliance Logic Troubleshooting ChecklistIssuePossible CauseRecommended ActionToo many devices are marked non-compliant`OR` logic is evaluating criteria globally without proper scope restrictions.Scope the policy assignment to specific device groups under Targets, or switch to `AND` logic if all conditions must be present.Expected non-compliant devices are not flagged`AND` logic is overly restrictive, requiring every condition to fail simultaneously.Switch to `OR` logic so that any single condition failure triggers non-compliance.BYOD / Personal devices are over-enforcedOwnership was not included as an `AND` condition, or the policy assignment is too broad.Create dedicated compliance policies scoped specifically to Corporate vs. Personal device groups.