Security and compliance in RMM: a practical playbook
Security theater in RMM wastes budget. A practical playbook covers the controls auditors actually care about and ships value from day one instead of waiting six months.
Security theater in RMM wastes budget. A practical playbook covers the controls auditors actually care about, and explains how to ship value from day one instead of waiting for a six-month compliance project to finish.
What auditors actually check
In our experience across SOC 2, ISO 27001, and HIPAA audits:
- Access logging. Who did what, where, when?
- Access controls. Are privileges scoped, reviewed, and revoked on departure?
- Change management. Are changes tracked, approved, and reviewable?
- Vulnerability management. Are patches tracked and deployed timely?
- Data handling. Where is data, who can see it, how long is it kept?
- Incident response. When something breaks, can you reconstruct what happened?
Everything else is either mechanically verifiable (cert validity, encryption strength) or a secondary concern.
The five RMM controls that matter
Control 1: full session audit
Every operator session (shell, RDP, script execution) generates an immutable log:
- Who (SSO identity)
- Where (which endpoint, scope)
- When (timestamp)
- What (commands, screen captures for privileged sessions)
Retention per compliance requirement (usually 1-7 years). Auditor question: “Show me every shell session Alice opened in September.” Should take you 30 seconds.
Control 2: RBAC with real teeth
Not just groups, scoped access:
- Role (support, ops, admin)
- Scope (tenant, environment, service)
- Action (read, write, execute, admin)
Review quarterly. Auto-revoke on SSO disable. Auditor test: deactivate a test user, verify access terminates within minutes.
Control 3: change-managed configuration
All operational config (monitors, alerts, policies, scopes) managed through:
- Version control
- Code review
- CI validation
- Audit trail of applied changes
Auditor test: “Who changed the monitoring threshold for payment-svc on September 14?” Should answer from git history.
Control 4: patch compliance reporting
Automated report per scope:
- Target patch level
- Actual patch level
- Deviations with documented exceptions
- Time-to-patch metrics
Scheduled monthly to compliance team. Auditor test: “What’s your patch compliance for PCI hosts?” Pull the report.
Control 5: data handling
Know:
- What data the RMM stores
- Where (region, provider)
- For how long
- Who can access it
Auditor test: “Is session capture data encrypted at rest?” Yes, AES-256. “Where?” ClickHouse in us-east-1 or eu-west-1 per tenant config.
What you don’t need
- Control frameworks matching other frameworks that match other frameworks (turtles all the way down)
- Quarterly security review theater where nothing changes
- Checkbox controls disconnected from actual behavior
- “Compliance dashboards” that don’t drive decisions
The pragmatic path to audit-ready
If you’re starting cold:
- Month 1. Enable session logging across the board. Turn on MFA at the IdP. Map roles to scopes.
- Month 2. Move ops config to version control. Set up quarterly access reviews.
- Month 3. Automate patch reporting. Document data flows.
- Month 4. Run a mock audit with a friendly auditor or consultant.
- Month 6. Real audit.
Teams that skip the mock audit often fail real ones on presentation, not substance.
What LynxTrac ships
- Immutable session audit out of the box
- RBAC with scope + role + action
- Config via API (pair with your IaC)
- Patch compliance reports
- Data residency per tenant
You still do the work of policy, process, and culture. Tools don’t replace those.
LynxTrac is free forever for up to 2 servers, no card required. If you want to try it on real infrastructure instead of reading about it: app.lynxtrac.com.
Related posts
LynxTrac 1.0.0 and what we mean by stable
LynxTrac is 1.0.0. The work that earned the number was bug fixing, not features, and the kind of bug we were still finding is the reason we finally cut it.
Ad-hoc scripts still need a paper trail
SSH in, run the fix, close the terminal. It worked, and six weeks later nobody can say what happened. What a script library and a recorded run change about that.
A release is not finished when it is applied
Most deploy tooling ends at apply. A release worth trusting has a verify stage after it, a rollback that is a button, and approvals recorded task by task.