Interactive Flow · SimpleSense.io · Michael Krawczyk
Patch Management & Flaw
Remediation — Interactive Model
Click any node to expand it. Work your way down the flow from initialization through to closure.
NIST SP 800-171 3.14.1 CMMC Level 2 · SI.L2-3.14.1 Click nodes to expand ↓
// patch_mgmt_operating_model
PHASE 0 Initialization
🖥️
Automate Server
ConnectWise Automate RMM · Central orchestration engine
▾
// rmm_platform
⚡ConnectWise Automate is the central RMM orchestration engine driving all patch policy enforcement, script execution, and endpoint inventory across all managed clients.
🔗All downstream patch policy groups, approval workflows, and deployment schedules are configured and managed from this server.
🔄
Sync Inventory from RMM / CMDB
Pull current asset inventory, patch status, group memberships
▾
// inventory_sync_scope
All managed endpoints with current OS version and patch status
Server and workstation classification per client record
Current patch group membership and assigned policy
Exception register — endpoints excluded from patching
Ring assignments (Pilot, Regular, Production)
PHASE 1 Scope & Exclusions
◆
Is patch or agent patching disabled?
Check disabled flag at location or agent level in RMM
▾
YES Disable patching for this location or agent. Stop processing — endpoint will not receive patches until flag is cleared.
NO Continue to exclusion policy check.
● Disabled — patching stopped for this endpoint
◆
Excluded by client policy?
Verify standing exclusion agreed upon with client
▾
YES Excluded from patching. Add to exception register. Requires signed client approval to change. Stop processing for this cycle.
NO Endpoint is in scope. Proceed to Phase 2 scheduling.
● Excluded — add to exception register
✓ In scope — continue to Phase 2
PHASE 2 Schedule & Cadence
📅
Cadence & Maintenance Windows Assigned
All endpoints receive a patch cadence and reboot window
▾
// schedule_parameters
🖥️ Workstations
Regular (overnight): 02:00 – 04:00 local time
Daytime track: Patches during business hours; relies on end user to reboot
Reboot reminder: Daily popup at 10:00 local until rebooted
🗄️ Servers
Unattended reboot window: 21:20 – 03:20 local (when approved)
Manual reboot: Technician-controlled outside window
Critical servers: Manual approval required
PHASE 3 Approval Governance
✅
Auto-Approve Monthly Microsoft Security Patches
Patch Tuesday releases · No manual review required
Auto-ApprovePatch Tuesday
▾
// auto_approval_scope
Microsoft Security patches (monthly Patch Tuesday cycle)
Critical and Important severity classifications are auto-approved
Reduces time-to-patch for known CVEs to within 48 hours of release
🚫
Decline Drivers by Default
Driver updates excluded from automation · Manual review required
Drivers DeclinedManual Review
▾
// driver_policy
All driver updates are declined by default in the RMM approval queue
Prevents unintended hardware compatibility regressions
Engineer must review and manually approve any driver update
Approved driver updates are tracked in the exception register
🧪
Monthly Update Scan — Pilot Ring, 7-Day Soak
Staged rollout · Pilot before Production
Pilot Ring7-Day SoakStaged Rollout
▾
// staged_rollout_policy
Each monthly update batch is staged to Pilot ring first
Minimum 7-day soak period in Pilot before Production promotion
Pilot ring includes representative endpoints from all tracks and clients
If Pilot ring shows issues — hold Production until root cause resolved
◆
Manual approval required?
Non-Microsoft patches, optional updates, third-party software
▾
NO Auto-approved scope — proceed directly to endpoint classification.
YES Hold for engineer review (7 days). Engineer reviews patch notes, CVE impact, and affected systems. Must approve or decline explicitly.
DECLINED Decline or defer patch. Document in exception register with engineer sign-off and reason code.
● Declined — documented in exception register
✓ Approved — proceed to classification
🚨
Failure Handling Standard
Applies to all deployment phases · PSA ticket · Escalation · On-call
All PhasesPSA TicketP1–P3
▾
// failure_handling_standard
PSA ticket created for every failed patch deployment
Escalation priority 1–3 assigned by criticality of affected system
On-call engineer alerted after hours for every server-class failure
Failed patches tracked in RMM with next retry window documented
Root cause documented before retry is permitted
◆
Classify Endpoint — Server or Workstation?
Determines which deployment track applies from this point
SERVER Route to Server Grouping track. Applies server policy groups, role-based criticality, and controlled reboot windows.
WORKSTATION Route to Workstation Grouping track. Applies workstation policy groups, ring assignments, and user-facing reboot prompts.
SPLIT Endpoint Classification Tracks
🗄️
Server Track
Grouping → Deployment → Post-Reboot Validation → Evidence & Closure
▾
PHASE 1 Server Grouping
Assign Server Patch Policy Group
Controls update approval and reboot behavior
▾
// server_patch_policy_groups
Do Not Patch
Manually Patch and Reboot
Auto Install, Manual Reboot
Auto Install, Auto Reboot (optional — use only when unattended reboot is approved)
↓
Assign Server Role Group (Criticality P1 → P3)
Role drives escalation priority during failure
▾
// server_role_groups
P1: Domain Controllers
P1: SQL Servers · App Servers
P2: File Servers · Web Servers
P2: Utility / Infrastructure Servers
P3: Backup or DR Servers
Optional: Virtualization Hosts, Exchange/Messaging, SMTP, Management Servers
↓
◆
Patch policy is Do Not Patch?
▾
YESExclude from patch automation. Add to exception register. Approval required to change status.
NOContinue to server deployment.
● Excluded — exception register
PHASE 4 Server Deployment
◆
Client has 2 or more servers?
▾
NO — Single Server No Test tier needed. Proceed directly to production maintenance window. Technician initiates patches via RMM. Schedule reboot 21:20–03:20 local.
YES — Pilot First Pilot Group Preview Deploy: Manually patch Pilot server. Verify health for 7 days. Promote remaining servers once validated.
↓
◆
Unattended reboot approved?
▾
YESSchedule auto reboot: 21:20 – 03:20 local time.
NOReboot remains technician-controlled. Technician schedules and confirms reboot manually.
PHASE 4 Post-Reboot Validation
Run Post-Reboot Validation Monitors
Verify all critical services are healthy after reboot
▾
// validation_checklist
Server online and RMM agent reporting healthy
DNS and DHCP services responding (where applicable)
Line-of-business applications accessible
LDB and production line services operational
SMTP / MTP services responding (where applicable)
Exchange services healthy (where applicable)
VPN connectivity test passed (where supported)
↓
◆
Production server healthy?
▾
YESProceed to Phase 5 Evidence & Closure.
NOFailure Handling — create PSA ticket, set escalation priority, hold deployment for this tier, block Production if critical.
PHASE 5 Evidence & Closure
Update PSA Compliance Ticket + Record Evidence
Close patch cycle tier with documented evidence
▾
// closure_requirements
PSA ticket updated with patch completion status
Reboot confirmation and timestamp recorded
Screenshot of patch compliance report attached
Close patch cycle tier in RMM cycle tracker
Evidence retained for compliance audit readiness
✓ Server patch cycle complete
🖥️
Workstation Track
Grouping → Track Setup → Ring Deployment → Evidence & Closure
▾
PHASE 1 Workstation Grouping
Assign Workstation Patch Policy Group + Track
Daytime vs Regular (overnight) track assignment
▾
// workstation_tracks
Regular (overnight): Patches and reboots 02:00 – 04:00 local. Fully automated.
Daytime: Patches during business hours. End user reboot prompt at 10:00 daily until rebooted.
Daytime posture requirement: Workstation must not be in sleep or hibernate mode during patch window.
↓
Assign Ring: Pilot or Regular
Pilot ring validates patches before Regular ring receives them
▾
// ring_structure
Pilot ring: Representative endpoints from both Daytime and Regular tracks. First to receive each patch batch.
Regular ring: Majority of workstations. Receives patches after 7-day Pilot soak period passes cleanly.
MostTest ring: Seamless membership — includes workstations from both tracks for cross-validation.
↓
◆
Patch policy is Do Not Patch?
▾
YESExclude from patch automation. Add to exception register.
NOContinue to Phase 3 Workstation Deployment.
● Excluded — exception register
PHASE 3 Workstation Deployment
◆
Workstation in Pilot or Test ring?
▾
YESNotify user reboot required. Run post-patch health check. Verify Pilot ring is clean before promoting to Production ring.
NOWorkstation is in Production ring. Wait for Pilot soak period (7 days) to complete before deployment.
↓
◆
Pilot ring verified healthy?
▾
YES7-day soak passed cleanly. Hold period complete. Promote to Production ring deployment.
NOHold patches. Do not promote to Production until Pilot issues are resolved. Create PSA ticket for failure.
⏸ Hold — Pilot not verified, Production blocked
↓
◆
Workstation track is Daytime?
▾
YES — DaytimeSend 10:00 popup reminder daily until user reboots. Auto-force reboot if no action after 3 days at next maintenance window.
NO — OvernightAuto reboot between 02:00 and 04:00 local time. No user intervention required.
↓
◆
Workstation rebooted and ring healthy?
▾
YESProceed to Phase 4 Evidence & Closure.
NOFailure Handling — create PSA ticket, default priority 2 unless client impact is higher. Notify support queue.
PHASE 4 Evidence & Closure
Update PSA Compliance Ticket + Close Patch Tier
Document evidence and mark cycle complete
▾
// closure_requirements
PSA ticket updated with patch completion and reboot confirmation
Baseline app and VPN connectivity verified
Patch cycle tier closed in RMM
Evidence retained for compliance audit readiness
✓ Workstation patch cycle complete
// end_of_flow