
audit
How to Audit Script Execution Across Clients
Practical steps for MSPs building cross-customer evidence for assessors-export, correlation, retention, and honest gap disclosure.
- Reproduce steps in trial
- Export audit evidence
- Attach to GRC binder
Updated 2026-06-14
Practical steps for MSPs building cross-customer evidence for assessors-export, correlation, retention, and honest gap disclosure.
Visual anchor before the full guide below.

audit
Practical steps for MSPs building cross-customer evidence for assessors-export, correlation, retention, and honest gap disclosure.
MSPs manage dozens or hundreds of end-customers under one operational team. Assessors rarely care about a single script-they ask whether governance scales: consistent approval, attributable execution, and exportable proof across the client base.
Building that evidence requires separating security audit from operational logs, scoping exports per review window, and documenting vendor gaps (SIEM connectors, immutability) without pretending they are solved.
Confirm Settings → Security keeps audit logging enabled unless your SSP documents a justified opt-out. Security Center should show audit logging on for production tenants.
Understand that opt-out skips tenant row writes-assessors may treat disabled audit as a finding. Use opt-out only with explicit risk acceptance.
Every production script should flow: publish → approve (where required) → queue → execute. Ad hoc runs bypassing the library undermine cross-client consistency. Migrate high-risk scripts first-patch-adjacent one-offs may remain on incumbent RMM until phased.
Platform script catalog helps standardize built-ins (restart, health checks) with reserved tags instead of per-tech snippets.
Use Web Audit logs (/audit) or GET /api/audit/export with:
Server-side row caps apply-split large windows into multiple exports rather than assuming unbounded bulk export (async bulk is backlog).
Trustholm tenant maps to your MSP organization. Customer/group scoping inside the tenant uses catalog patterns-ensure exports include fields your GRC uses to slice per end-client (group, agent scope, or tags per your deployment practice).
If your narrative is per end-customer SOC 2, attach export slices per customer with consistent methodology documented in your methodology memo.
Copy exports to WORM storage or GRC vaults you operate. Acknowledge Trustholm append-only application behavior versus DBA mutability gap. Compensate with restricted database operator access and change logging on infrastructure.
Product export alone is insufficient. Include:
JSON/CSV export ships today. Native Microsoft Sentinel DCR/Event Hub connector and ASIM normalization are backlog. If your SSP claims real-time SIEM ingestion, show the forwarding pipeline you built-or mark as planned.
Technicians should explain one system of record for signed scripts, not a patchwork of RMM libraries. vCISOs should demo export + IDE lineage in under fifteen minutes. Consistency across clients is the goal-not perfect tooling, but defensible process.
Script API exports on a schedule (weekly incremental, monthly full) into immutable S3 or Azure Blob with object lock. Tag exports with tenant code and review period.
Alert when export row counts drop unexpectedly-may indicate audit toggle changes or integration failure. Document runbook for re-export after clock skew incidents.
Dual-system estates should tag exports with source system metadata so assessors understand coverage boundaries during migration years.
Link reviewers to /trust/audit-and-logging and /use-cases/script-auditability for aligned narratives on export cadence and GRC ingestion.
Assign a reviewer to open trial tenant, navigate documented UI paths, and capture screenshots with timestamps. Export audit JSON for same session.
Store in immutable GRC folder. Compare results to this article quarterly.
When Shipped/Gap rows change in trust hub, re-run reproduction within ten business days. Attach limitations memo for WORM audit and Sentinel connector backlog.
Include DB operator access policy from hosting provider. Pair technical evidence with customer governance documents-policies, pentest summaries, IR runbooks.
Never substitute marketing copy for reproduced checks in front of assessors. Treat this appendix as a living runbook section owned by security engineering, not a one-time audit artifact.
Schedule annual refresh aligned with trust hub version stamps and major product releases. Link each reproduction run to a change ticket for traceability.
Distribute updated article PDFs to customer-facing teams when dateModified changes. Archive prior versions for twelve months to support assessor lookback questions.
When citing this article externally, include dateModified and pillar metadata in footnotes so readers know content freshness. Internal enablement should link pillar tags to trust hub sections for consistent customer messaging.
Add article slug to internal wiki index for sales engineering quick lookup during live questionnaire calls.
Security audit for attributable privileged actions. HTTP logs for operational troubleshooting. Submit both roles in your deployment architecture doc.
Either migrate evidence-critical scripts to Trustholm or document dual-system risk in your SSP. Mixed estates are common; honesty beats silent gaps.
JSON/CSV typically imports with manual mapping. Native GRC connectors are not claimed-plan integration labor in audit season.
Audit is tenant-wide toggle, not per-script. Per-script suppression is not a shipped pattern-plan governance accordingly.
Align with GRC sync policy-daily or weekly incremental plus point-in-time for examinations. Automate via API where your compliance engineering team scripts it.