OpenFrame is on your phone now!

Skip to content

Device Compliance & Evidence

BEST PRACTICESCOMPLIANCEDOCUMENTATIONGUIDEOPENFRAMEPATCH MANAGEMENTPOLICYSECURITY

Phase 9 — Security & Access Control · Step 4

Section

October 27, 2026

Published

Vladislav Marchenko

Vladislav Marchenko

Head Of Marketing

Reviewed 02/10/2026

Device Compliance & Evidence

Phase 9 — Security & Access Control · OpenFrame Onboarding

When a client asks "are our machines patched and in policy?" — or an auditor does — the Compliance tab on a device is where you get the answer. It pulls patch status, applied policies, and compliance checks into one view per machine. This guide covers reading it as part of your security and accountability story.


Where it is

Open a device from Devices, then the Compliance tab on its detail page. It sits naturally alongside Audit Logs (Phase 9) — together they're your "who did what" and "what state is it in" evidence trail.


Patch Management

The top block, Patch Status, tells you how current the machine is:

  • Last Installed — when patches were last applied (or Never).
  • Pending Patches — whether updates are waiting (No is what you want).
  • Status — the headline: Up to Date or behind.

This is the fastest read on whether a device is a patching risk — and it's the other side of Tracking Device Vulnerabilities (Phase 4), since missing patches are a common source of exposure.


Policy Compliance

The next block shows which policies govern the device and how they're layered:

  • Applied Policies — what's in effect at each level: Agent Policy, Site Policy, Client Policy, Default Policy. None means nothing is set at that level.
  • Policy Configuration → Policy Inheritance — when Enabled, a device inherits policy down the hierarchy (Agent → Site → Client → Default), so you can set a baseline at the client level and let machines pick it up automatically (this is the multi-tenancy structure from Organizations & Multi-Tenancy Overview).

The inheritance model is what lets you manage policy per client without configuring every machine by hand.


Compliance Checks

The Compliance Checks block summarizes the device's pass/fail posture — Total Checks, Passing (and failing) — giving you a single scorecard of whether it meets the standards you've set.


Using it as evidence

This tab is built for accountability:

  • Answer the client. "Are we patched and compliant?" — screenshot or summarize the tab.
  • Prove it for audits. Patch status, applied policies, and passing checks together form a per-device compliance record.
  • Find the gaps. A device showing None for every policy, Pending Patches: Yes, or failing checks is one to fix before it's a finding.

Quick checklist

  • Opened a device's Compliance tab
  • Read Patch Status (Last Installed, Pending Patches, Status)
  • Checked Applied Policies across Agent / Site / Client / Default
  • Confirmed whether Policy Inheritance is enabled
  • Reviewed Compliance Checks (passing vs. failing)
  • Flagged devices with no policy, pending patches, or failing checks

What's next

That rounds out Phase 9 — Security & Access Control on the device side. Patching and vulnerabilities connect back to Tracking Device Vulnerabilities (Phase 4); the people and AI controls live in the other Phase 9 guides.


Based on OpenFrame v0.9.19. Compliance data, policy levels, and checks evolve between releases — what's in your console wins. Compliance views are an aid to your security process, not a substitute for it.

Vladislav Marchenko

Head Of Marketing

Hi all! My name is Vlad and I’ve been brought on to head the marketing team at Flamingo. Thankfully, this isn’t the first time I will be building a marketing department from scratch, so the experience should come in handy. Now it’s time to dive into the world of MSPs and find myself in this new world.

Related Content

Frequently Asked Questions

/onboarding-guides/device-compliance-evidence

Still deciding?

Mingo answers from our docs and customer stories.

Loading related content and questions