From Compliance
Use this skill when a compliance control (CIS, SOC 2, HIPAA, or a cyber-insurance questionnaire line item) needs to be traced to concrete, retrievable evidence from connected MSP tooling rather than answered from memory or assumption. Covers how to resolve a control statement to specific gateway tool calls across CIPP (M365/Entra), Liongard (infrastructure inspections), and IT Glue/Hudu (documentation), and the critical distinction between evidence that proves a control is actually met versus evidence that only proves the control is written down as policy.
How this skill is triggered — by the user, by Claude, or both
Slash command
/compliance-pack:evidence-mappingWhen to use
When mapping a named control or questionnaire line item to live tool evidence, when deciding whether a piece of evidence proves configuration or only proves documentation, or when assembling a source-cited evidence package for an audit. Use when: compliance evidence, control evidence, evidence mapping, map this control, what proves this control, audit evidence, evidence source, is this control met, documented vs enforced, policy vs configuration.
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Every compliance framework and every cyber-insurance questionnaire ultimately reduces to the same operation: take a control statement in English ("MFA is enforced for all users," "access to PHI systems is logged," "endpoint detection and response is deployed fleet-wide") and produce evidence that either supports or contradicts it. The failure mode this skill exists to prevent is answering from ...
Every compliance framework and every cyber-insurance questionnaire ultimately reduces to the same operation: take a control statement in English ("MFA is enforced for all users," "access to PHI systems is logged," "endpoint detection and response is deployed fleet-wide") and produce evidence that either supports or contradicts it. The failure mode this skill exists to prevent is answering from a policy document, a vendor's marketing claim, or a technician's recollection when a live tool query would give a verifiable answer. If a tool can answer it, pull the tool. If no connected tool can answer it, say so explicitly — never fill the gap with an assumption.
Evidence in an MSP's toolchain comes from three vendor families, each proving a different kind of thing:
Treat these as different evidentiary weights, not interchangeable sources.
This is the single most important judgment call in evidence mapping, and getting it wrong is what turns an evidence package into a liability during an actual audit.
cipp__list_mfa_users returns per-user MFA registration state, or cipp__list_conditional_access_policies shows a policy requiring MFA scoped to "All users." This is evidence the control is met.cipp__list_mfa_users shows 40% of users unregistered). This is the most actionable finding of all — surface it prominently, never average it away.When assembling an evidence package, always label each piece of evidence with which of these three states it represents. Never let a documentation hit stand in for a configuration check when a configuration check is possible. If only documentation is available (no connector exists for the underlying system), say the control is "documented, unverified" — not "met."
| Control (typical phrasing) | Vendor family | Tool calls | Evidence type |
|---|---|---|---|
| MFA enforced for all users | CIPP | cipp__list_mfa_users, cipp__list_conditional_access_policies | Configured |
| Conditional access restricts legacy auth / risky sign-in | CIPP | cipp__list_conditional_access_policies, cipp__list_named_locations | Configured |
| Tenant meets baseline security standards (CIS-aligned) | CIPP | cipp__list_standards, cipp__run_standards_check, cipp__list_bpa | Configured |
| Email authentication (SPF/DKIM/DMARC) configured | CIPP | cipp__list_domain_health | Configured |
| Privileged/admin access is scoped and reviewed | CIPP | cipp__list_gdap_roles, cipp__list_groups, cipp__list_users | Configured |
| Access and admin activity is logged | CIPP | cipp__list_audit_logs, cipp__list_logs | Configured |
| Server/network baseline configuration is known and current | Liongard | liongard__systems_list, liongard__inspections_run, liongard__environments_get | Configured (point-in-time) |
| Device and identity inventory is current | Liongard | liongard__inventory_devices, liongard__inventory_identities | Configured |
| A named policy/procedure exists (IR plan, access policy, patch policy) | IT Glue / Hudu | itglue__search_documents, itglue__get_document | Documented |
| Configuration item is recorded with current state | IT Glue | itglue__search_configurations, itglue__get_configuration | Documented (should be cross-checked against Liongard/CIPP if both exist) |
| Credential storage/rotation practice exists | IT Glue | itglue__search_passwords (existence and metadata only — never surface secret contents) | Documented |
This table is representative, not exhaustive — the same pattern (resolve the control's subject matter to the vendor family that can observe it, then pick configured evidence over documented evidence whenever both are possible) applies to any control not listed here.
A given client will rarely have every vendor family connected. When a vendor family needed for a control is not connected in Conduit (confirm via conduit__search_tools), the control is neither "met" nor "failed" — it is unable to verify. Report it as such, name the specific vendor family that would resolve it, and move on. Never substitute a documented-evidence hit for a missing configured-evidence source without flagging the substitution explicitly.
conduit__search_tools → call the specific tool(s) → classify result as Configured / Documented / Contradicted / Unable to Verify.standards-drift skill for the deeper pattern).conduit__search_tools shows no compliance-relevant connector for a control's subject matter, record Unable to Verify and name the missing connector type (e.g., "no EDR connector available for this client").conduit__search_tools to confirm before referencing it in output.npx claudepluginhub wyre-technology/msp-claude-plugins --plugin compliance-packGuides completion of development work by verifying tests, detecting environment, and presenting structured options for merge, PR, or cleanup.
Guides creation and editing of skills using test-driven development with pressure scenarios and subagents to verify agent compliance.
Dispatches multiple subagents concurrently for independent tasks without shared state. Use when facing 2+ unrelated failures or subsystems that can be investigated in parallel.