An RMM platform can reach every device you manage. That makes it one of the highest-value targets in your environment, and it is why we publish how the platform is secured instead of asking you to assume it.
Please read this first, because accuracy matters more than marketing. This page describes the security controls implemented in the ITSupport RMM platform and the configurations we make available to help you meet obligations under frameworks such as HIPAA, PCI DSS and NIST SP 800-171 / CMMC. It is not a claim that ITSupport RMM holds a SOC 2, ISO 27001, HIPAA, PCI or FedRAMP certification or authorization, and it is not a claim that using our platform makes your organization compliant with any framework. Compliance is an organizational outcome that depends on your policies, your people and your whole environment. If you require attestation documents or a completed security questionnaire for a vendor assessment, contact us at Info@itsupport-rmm.com and we will tell you precisely what documentation exists today.
All agent-to-platform and browser-to-platform traffic uses TLS 1.2 or higher with modern cipher suites. Agents pin the expected certificate chain, so a network device performing TLS interception cannot silently sit in the middle of a management channel.
Stored telemetry, inventory, configuration, credentials and audit records are encrypted at rest. Credential vault entries receive an additional layer of application-level encryption so they are not readable from a database copy alone.
Multi-factor authentication is mandatory for every console user on every plan, not an optional upgrade. Password policy, session timeout and concurrent-session limits are configurable. Enterprise plans support SSO/SAML with group-to-role mapping.
Role-based access control with least-privilege defaults. Roles are scoped to tenants, sites and device groups, and sensitive capabilities — running scripts at organization scope, retrieving vault credentials, changing retention — are separately grantable.
Console logins, remote sessions, script executions, patch approvals, policy changes, credential retrievals, API calls and user administration are recorded with timestamp, actor and source address. Audit records are append-only for users and exportable for your own SIEM.
An approval workflow means unreviewed code cannot be executed across a fleet. Scripts have owners, version history and recorded output, so "what did that script actually do on 400 machines" is an answerable question.
Tenant boundaries are enforced in the data access layer and in API authorization, not only in the user interface. Technicians operating in one client's context cannot enumerate another client's devices.
Installers and agent binaries are code-signed. The agent validates update packages before applying them, runs as a documented service, appears in installed-programs lists, and can be removed with a published command.
Administrative access to production infrastructure is restricted to authorized personnel using MFA, is logged, and follows least privilege. Changes move through review before release, and we maintain documented backup and restoration procedures.
For customers with a US billing address, platform data is processed and stored in United States data center regions. That includes monitoring telemetry, asset inventory, alert history, script output, session metadata and audit records.
| Data category | Default retention |
|---|---|
| Performance telemetry (raw) | 30 days, then aggregated |
| Performance telemetry (aggregated) | 13 months |
| Asset and software inventory | Current state plus 12 months of change history |
| Alert history | 13 months |
| Script execution output | 90 days |
| Remote session metadata | 12 months (Core), 24 months (Professional) |
| Audit log | 12 months (Core), 24 months (Professional), custom (Enterprise) |
| Account and billing records | As required by US tax and accounting law |
Session recordings, where you enable them, are stored only for the retention period you configure and are accessible only to roles you authorize. Recording is off by default and, when enabled for attended sessions, the end user is shown a notice.
Transparency about a privileged agent is not optional, so here is the boundary.
Full detail, including our role as a data processor for the data you place in the platform, is in the Privacy Policy.
Frameworks demand evidence. These are the platform outputs that map to the control families customers ask about most often.
| Requirement theme | Framework examples | Platform capability |
|---|---|---|
| Vulnerability and patch management | HIPAA Security Rule, PCI DSS Req. 6, NIST 800-171 3.14 | Patch policies, ring deployment, compliance reporting with history |
| Access control and least privilege | PCI DSS Req. 7, NIST 800-171 3.1 | RBAC, tenant scoping, granular capability grants |
| Strong authentication for administrative access | PCI DSS Req. 8, NIST 800-171 3.5 | Mandatory MFA, SSO/SAML on Enterprise, session controls |
| Audit and accountability | HIPAA audit controls, PCI DSS Req. 10, NIST 800-171 3.3 | Audit log with actor, action, timestamp; export for SIEM |
| Configuration management | NIST 800-171 3.4, CIS baselines | Policy baselines, drift detection, configuration reporting |
| Asset inventory | CMMC asset management, insurance questionnaires | Hardware and software inventory with dynamic grouping |
| Incident detection and response support | HIPAA contingency planning, NIST 800-171 3.6 | Alerting, automated remediation, session and script records |
If you believe you have found a security vulnerability in our platform, agent or website, email Info@itsupport-rmm.com with the subject line "Security disclosure". Please include reproduction steps and avoid testing that degrades service for other customers or accesses data that is not yours. We acknowledge reports within two business days, keep you informed while we investigate, and will not pursue legal action against researchers who act in good faith under these terms.
We maintain a documented incident response process covering detection, containment, eradication, recovery and post-incident review. If a security incident affects your data, we will notify the account's designated contacts without undue delay, describe what is known and what is still under investigation, state what we are doing about it, and follow up with a written summary. Notification timelines required by applicable US state breach notification laws are respected.
Security in a management platform is genuinely shared. The controls we provide only work if they are used, so we state plainly what sits on your side:
Our Acceptable Use Policy defines the boundaries of permitted use, including the requirement that you have authorization for every device you manage through the platform.
Send us your questionnaire. We will complete it with accurate answers, including the questions where the honest answer is "not yet". Enterprise accounts get a named contact for the process.
+1 717 823 6666 · Info@itsupport-rmm.com