When Compliance Demands Explicit Approval: How Caisey's Granular Gates Replace the 'Run-All-Scripts' RMM Model for PCI-DSS Clients

When a client is subject to PCI-DSS or HIPAA, the MSP's remote troubleshooting process becomes part of the compliance boundary. Auditors want to see not just that a fix was applied, but that every diagnostic command was explicitly authorized before it ran. Traditional RMM tools—NinjaOne, Datto, ScreenConnect—either run scripts under a blanket permission model or rely on session-wide elevation that leaves no per-action consent record. Caisey's approval-gated endpoint actions give MSPs a defensible way to handle these requirements, because each command can require separate consent with a permanent audit trail.

The Problem with Blanket Script Permissions

Most RMM platforms treat script execution as a binary: either the technician has permission to run scripts on a client's machines, or they don't. Once that permission is granted, every PowerShell one-liner, every registry edit, every service restart happens without further checks. For a PCI-DSS environment, that's a gap. Requirement 10 of PCI-DSS calls for logging all access to cardholder data environments, and Requirement 7 mandates need-to-know access. A blanket "run all scripts" model doesn't prove that a specific command was necessary for a specific incident. It only proves that the technician had the key to the castle.

Some MSPs work around this by having clients watch over their shoulder during a screen-sharing session, or by saving RMM logs as PDFs after the fact. Neither approach creates a per-command consent record that an auditor can verify independently. Screen-sharing sessions capture video, not structured command history. RMM logs show what ran, but not who approved it or when.

Concrete Scenario: Retail POS Intermittent Network Drops

Consider a retail client with a Point of Sale system that intermittently loses network connectivity. The MSP needs to run several diagnostic commands: netsh interface show interface to check adapter state, ipconfig /displaydns to inspect DNS cache, netstat -b to identify active connections, and ping tests to the payment gateway. Each of these commands touches the cardholder data environment indirectly—the POS system processes credit card transactions.

With Caisey, the technician opens the client's workspace from the browser, selects the enrolled POS endpoint, and starts a session. The first command—say, netsh interface show interface—is typed into the Caisey runtime chat. Before it executes, the endpoint displays an approval prompt to the on-site manager or a designated approver. The prompt shows the full command text, the technician's name, the client workspace, and a brief description. The manager can approve, reject, or request more context. Only after approval does the command run, and its output appears in the session transcript.

The technician then sends the next command, and the cycle repeats. Each approval is timestamped and linked to the specific command. The session transcript becomes a time-stamped, reviewed log that satisfies PCI-DSS Requirement 10.6 for reviewing logs of access to cardholder data.

Comparison with Traditional Tools

ScreenConnect's "request elevation" feature is session-wide. Once the client clicks "Allow," the technician has elevated access for the duration of the session. There is no way to require separate consent for each command. NinjaOne's script execution logs the script name and result, but the script runs under the technician's existing permissions—no per-action approval. Datto RMM's command line interface similarly assumes the technician already has the right to run any command.

Caisey's model is different because the approval gate is per-command, not per-session. The client or approver sees exactly what will run before it runs. This granularity is what auditors look for: evidence that each action was individually authorized. It also protects the MSP: if a command accidentally causes an issue, the approval record shows that the client explicitly consented to that specific action.

Workflow Walkthrough

Here's how a typical PCI-DSS compliant troubleshooting session works in Caisey:

1. **Enroll the device.** The POS endpoint is enrolled with the Caisey runtime, either during initial setup or via a remote installer. Enrollment creates a persistent machine card in the client workspace.
2. **Group under client workspace.** The endpoint is assigned to the retail client's workspace. Caisey's Clerk-based org isolation ensures that the technician can only see and interact with machines in that workspace.
3. **Initiate a session.** From the browser console, the technician selects the endpoint and starts a session. The runtime connects through Caisey's bridge, establishing a secure channel.
4. **Send the first command.** The technician types netsh interface show interface into the runtime chat. The command is sent to the endpoint, but it does not execute immediately. Instead, the endpoint shows an approval prompt.
5. **Wait for approval.** The on-site manager sees the prompt on the POS screen (or via an out-of-band notification). They review the command and approve it. The technician sees the approval status in the browser.
6. **See the result.** The command executes, and output appears in the session transcript. Both the technician and the approver can see the result.
7. **Repeat.** The technician sends the next command—ipconfig /displaydns—and the process repeats. Each command is individually approved.
8. **End the session.** When diagnostics are complete, the session ends. The transcript is saved and can be shared as a public reviewed share or exported for compliance reporting.

The entire workflow takes minutes, and the resulting transcript is a permanent, unalterable record of every command and its approval.

The Edge: Clerk-Based Org Isolation

Caisey's Clerk-based org isolation adds another layer of compliance protection. Even if a technician accidentally selects the wrong client workspace—say, they meant to work on a different retail client—the approval gate prevents action on unauthorized machines. The approval prompt appears on the endpoint, and the on-site manager for that client would see a command they didn't expect. They can reject it, and the technician is immediately aware of the mistake. This cross-client safety net is built into the architecture, not bolted on as a policy.

For PCI-DSS, this isolation is critical. Requirement 7 mandates that access to cardholder data be restricted on a need-to-know basis. Clerk isolation ensures that a technician working on Client A's POS system cannot accidentally run a command on Client B's POS system without explicit approval from Client B's approver.

Conclusion: A Contractual Advantage

For MSPs who want to upsell compliance-ready support, Caisey's approval gates are a differentiator that makes "we have proof of consent" a contractual advantage. When a prospect asks how you handle PCI-DSS requirements, you can point to a model where every command is individually authorized, every approval is logged, and every session is isolated by client. That's a stronger answer than "our RMM logs everything." In a compliance audit, the difference between a blanket permission model and per-command approval can be the difference between a pass and a finding.