Technical SOPs
RMM Policy Set (Action1) — Windows + Mac
RMM Policy Set (Action1) — Windows + Mac
The standard Action1 RMM policy applied to every customer group at onboarding (Action1 SOP Part C / Engineer Runbook step 1). Two policies, assigned by OS: one Windows (PC), one Mac. Grounded in what Action1 actually automates — Action1 does app + minor-OS patching on both platforms via patch policies, runs scripts for security configuration, and raises alerts/automations; it is not an MDM (enforced config-profiles = Intune) and not the EDR (detection = Huntress).
Replaces the Syncro policy set. This SOP replaces the retired
rmm-syncro/policy-set.md. The RMM leg moved to Action1 peroperations-only/strategy/syncro-decommission-and-function-map.md. The patch SLA, maintenance window, and the FileVault-OFF / BitLocker-OFF critical alert carry over unchanged; the mechanism (native patch manager + script-driven Mac) is now Action1.
Patch SLA (both platforms — unchanged from the prior policy)
| Severity | Deploy within |
|---|---|
| Critical | 7 days |
| High | 30 days |
| Standard / optional | 60 days |
This is the same bar the Readiness Report recommends to firms (C-09) — we hold ourselves to what we sell. Patch compliance is a monthly-report posture chip and feeds the compliance evidence.
Maintenance / reboot window (both)
Install in an after-hours window, notify the user, allow short deferral, then force a reboot once a patch has been pending 7 days. Set the window per customer from the Deployment Questionnaire (their stated maintenance window / change-control constraints), configured on the Action1 patch automation for the group.
🖥️ Windows (PC) policy
Patching — Action1 patch policy / automation
- Auto-approve Critical + Security patches; install in the maintenance window.
- Third-party app patching (browsers, Adobe Reader, Java, Zoom, 7-Zip, etc.) on the same SLA — this is an Action1 strength (a large built-in third-party catalog).
- Defer feature/optional updates → manual approval.
- Per-asset exclusions for any client hold rule.
- Force reboot after 7 days pending.
Monitors / alerts → notification
Action1 raises these via alerts/automations (notification to the shared inbox / engineer — there is no PSA ticket queue in Action1; ticketing is the shared-inbox interim model). EDR-health alerting is Huntress’s job, surfaced from the Huntress portal — Action1 confirms the agent’s presence, Huntress confirms detection health.
| Monitor | Threshold | Severity |
|---|---|---|
| Offline | > 30 min (business hours) | alert |
| Disk free | < 10% / < 5% | alert / critical |
| RAM | > 90% sustained 15 min | alert |
| CPU | > 90% sustained 15 min | alert |
| BitLocker encryption | OFF / no escrowed key | critical (the Windows encryption control — mirrors the Mac FileVault monitor; see C-10 SOP) |
| Huntress agent present | agent missing on a managed endpoint | critical (detection health itself = Huntress portal) |
| Pending reboot | > 7 days | alert |
| Backup agent | failed job | alert (backup vendor is an open item — see Honest limits) |
| Disk SMART | failure predicted | critical |
Automation
- Weekly maintenance script (temp cleanup, service-health check) via the Action1 script library.
- Auto-remediation: restart stuck critical services.
🍎 Mac policy
Patching
- App + minor-macOS patching via Action1 patch policy on the SLA.
- Third-party Mac apps: via Action1’s catalog / scripts where available.
- Install in the maintenance window; enforce reboot per macOS update requirements.
- Honest limit: Action1 does not do major macOS version upgrades or OS-vuln discovery — track major-OS upgrades via Intune or a scheduled manual step; don’t claim Action1 covers them.
Monitors / alerts → notification
| Monitor | Threshold | Severity |
|---|---|---|
| Offline | > 30 min | alert |
| Disk free | < 10% | alert |
| FileVault encryption | OFF / no escrowed key | critical (the Mac encryption control — see C-10 SOP) |
| Huntress agent present | agent missing | critical (detection health = Huntress portal) |
| macOS update | overdue vs SLA (app/minor only) | alert |
| Backup status | failed | alert (backup vendor is an open item) |
Automation
- Scheduled
softwareupdate/ patch check (daily) via script. - Scripted maintenance (cache cleanup).
- Security configuration is script-driven, not enforced-profile: enable/verify FileVault
(
fdesetup), firewall (socketfilterfw), Gatekeeper, baseline checks. Enforced FileVault that re-applies if changed is Intune (Business Premium) or Mosyle free (fallback) — not Action1.
Honest limits (state these; don’t overclaim)
- Action1 is RMM, not MDM. Enforced config-profiles / enforced FileVault & BitLocker = Intune (or Mosyle free on Mac). Action1 applies security settings via scripts.
- Action1 is not the EDR. Detection/SOC = Huntress; Action1 deploys the agent and confirms its presence.
- Mac patching is app + minor-OS only — no major macOS upgrades, no OS-vuln discovery.
- No PSA/ticketing in Action1. Monitor alerts go to the shared-inbox interim model
(
syncro-decommission-and-function-map.mdrow 7, open gap). - Backup monitoring assumes a backup agent/vendor — the backup vendor is an open item (C-12/
C-13;
syncro-decommission-and-function-map.md). Wire the backup-failure monitor once the vendor is selected; don’t assert it against a tool that isn’t chosen.
Where this applies
- Created once in Action1 (two OS-scoped policies), assigned per asset OS, attached to every customer group at onboarding (Action1 SOP Part C + Engineer Runbook step 1).
- Patch compliance reporting drives the monthly-report patch chip + the compliance evidence appendix.
”Done” means
- Windows + Mac Action1 policies built with the SLA, maintenance window, monitors/alerts, and automation above
- Each customer group assigned the correct OS policy at onboarding
- Patch-compliance reporting enabled (feeds the monthly posture chip)
- Per-customer maintenance window set from the Deployment Questionnaire
- FileVault-OFF / BitLocker-OFF critical alert active (the encryption monitor behind C-10)