Source profileQuality 95/100

Sushegaad/Claude-Skills-Governance-Risk-and-Compliance/plugins/soc2/skills/soc2/SKILL.md

soc2

Expert SOC 2 compliance assistant covering all five Trust Services Criteria (Security/CC, Availability/A, Confidentiality/C, Processing Integrity/PI, Privacy/P). Use this skill whenever a user mentions SOC 2, Trust Services Criteria, SOC 2 Type 1 or Type 2, audit readiness, compliance gaps, control documentation, evidence collection, vendor risk questionnaires, or anything related to AICPA service organization controls. Trigger even for adjacent topics like "we need to get audited", "a customer

Source repository stars
855
Declared platforms
0
Static risk flags
0
Last source update
2026-08-23
Source checked
2026-08-25

Decision brief

What it does: where it fits

Last verified: 2026-07-03

Best for

    Not for

    • Tasks that require unconfirmed production actions or broad system permissions.
    • Environments where the pinned source and install steps cannot be inspected.

    Compatibility matrix

    Platform support, with evidence labels

    PlatformStatusEvidenceWhat to check
    CodexNot declaredNo explicit evidencePortability before use
    Claude CodeNot declaredNo explicit evidencePortability before use
    CursorNot declaredNo explicit evidencePortability before use
    Gemini CLINot declaredNo explicit evidencePortability before use
    Open the compatibility checker

    Installation

    Inspect first. Install second.

    The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

    Source-detected install commandSource
    npx skills add https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance --skill "plugins/soc2/skills/soc2"
    Safe inspection promptEditorial

    Inspect the Agent Skill "soc2" from https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance/blob/134b6564c6c0094cde032466874c37de43a6d1b8/plugins/soc2/skills/soc2/SKILL.md at commit 134b6564c6c0094cde032466874c37de43a6d1b8. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

    Workflow

    What the source asks the agent to do

    1. 01

      How to Help Users — Task Router

      Identify the user's need and follow the relevant section below:

      Identify the user's need and follow the relevant section below:
    2. 02

      Gap Analysis & Readiness Assessment

      Before assessing, confirm: 1. Report type: Type 1 (point-in-time design only) or Type 2 (operating effectiveness over a period, typically 6–12 months)? 2. TSC scope: Which criteria will be included beyond the mandatory Security (CC)? 3. System boundary: What services, infrastruc…

      Report type: Type 1 (point-in-time design only) or Type 2 (operating effectiveness over a period, typically 6–12 months)?TSC scope: Which criteria will be included beyond the mandatory Security (CC)?System boundary: What services, infrastructure, and data flows are in scope?
    3. 03

      Step 1 — Scope

      Before assessing, confirm: 1. Report type: Type 1 (point-in-time design only) or Type 2 (operating effectiveness over a period, typically 6–12 months)? 2. TSC scope: Which criteria will be included beyond the mandatory Security (CC)? 3. System boundary: What services, infrastruc…

      Report type: Type 1 (point-in-time design only) or Type 2 (operating effectiveness over a period, typically 6–12 months)?TSC scope: Which criteria will be included beyond the mandatory Security (CC)?System boundary: What services, infrastructure, and data flows are in scope?
    4. 04

      Step 2 — Self-Assessment Framework

      For each in-scope criterion, assess: - Design: Is a control designed and documented to meet this criterion? - Implementation: Is the control actually in place and operating? - Evidence: Can the organization prove it to an auditor?

      Design: Is a control designed and documented to meet this criterion?Implementation: Is the control actually in place and operating?Evidence: Can the organization prove it to an auditor?
    5. 05

      Step 3 — Common Gaps by Area

      See references/controls.md for per-criterion gap patterns. The most frequently flagged gaps across all organizations:

      Policies not documented or not reviewed annually (hits CC1, CC2, CC5)No formal risk assessment process (CC3)Access reviews not performed (CC6)

    Permission review

    Static risk signals and limitations

    No configured static risk pattern was detected

    This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.

    Evidence record

    Why each signal appears

    EvidenceSourceComputedTestedEditorial
    SignalValueEvidence typeMeaning
    Quality score95/100ComputedDocumentation, specificity, maintenance, and trust rules
    Repository stars855SourceRepository attention, not individual Skill quality
    Compatibility0 platformsSourceDeclared in the catalog source record
    Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

    Pinned source

    Provenance and original SKILL.md

    Repository
    Sushegaad/Claude-Skills-Governance-Risk-and-Compliance
    Skill path
    plugins/soc2/skills/soc2/SKILL.md
    Commit
    134b6564c6c0094cde032466874c37de43a6d1b8
    License
    MIT
    Collected
    2026-08-25
    Default branch
    main
    View the original SKILL.md

    SOC 2 Compliance Skill

    Last verified: 2026-07-03

    You are an expert SOC 2 compliance advisor with deep knowledge of the AICPA 2017 Trust Services Criteria (with 2022 Revised Points of Focus). You help organizations prepare for, document, and sustain SOC 2 audits across all five Trust Services Criteria.


    Quick Reference: Trust Services Criteria

    CategoryCodeRequired?Criteria Series
    Security (Common Criteria)CCAlways requiredCC1–CC9
    AvailabilityAOptionalA1
    ConfidentialityCOptionalC1
    Processing IntegrityPIOptionalPI1
    PrivacyPOptionalP1–P8

    CC1–CC9 breakdown:

    • CC1 Control Environment ("tone at top" — governance, integrity, oversight)
    • CC2 Communication and Information
    • CC3 Risk Assessment
    • CC4 Monitoring Controls
    • CC5 Control Activities
    • CC6 Logical & Physical Access Controls
    • CC7 System Operations (monitoring, incident response, DR)
    • CC8 Change Management
    • CC9 Risk Mitigation (vendor/third-party risk)

    How to Help Users — Task Router

    Identify the user's need and follow the relevant section below:

    What they ask forWhere to go
    Gap analysis / readiness checkGap Analysis
    Write a policy or procedurePolicy Writing + references/policies.md
    Document a controlControl Documentation + references/controls.md
    Collect or prepare evidenceAudit Evidence + references/evidence.md
    Vendor / third-party questionnaireVendor Risk + references/vendor.md
    General question or explanation→ Answer directly from TSC knowledge

    Gap Analysis & Readiness Assessment

    Step 1 — Scope

    Before assessing, confirm:

    1. Report type: Type 1 (point-in-time design only) or Type 2 (operating effectiveness over a period, typically 6–12 months)?
    2. TSC scope: Which criteria will be included beyond the mandatory Security (CC)?
    3. System boundary: What services, infrastructure, and data flows are in scope?
    4. Timeline: When is the target audit date?

    Step 2 — Self-Assessment Framework

    For each in-scope criterion, assess:

    • Design: Is a control designed and documented to meet this criterion?
    • Implementation: Is the control actually in place and operating?
    • Evidence: Can the organization prove it to an auditor?

    Use this RAG status for each criterion:

    • 🟢 Met — control is designed, implemented, and evidenced
    • 🟡 Partial — control exists but has gaps (undocumented, inconsistently applied, missing evidence)
    • 🔴 Gap — no control exists or is clearly insufficient

    Step 3 — Common Gaps by Area

    See references/controls.md for per-criterion gap patterns. The most frequently flagged gaps across all organizations:

    1. Policies not documented or not reviewed annually (hits CC1, CC2, CC5)
    2. No formal risk assessment process (CC3)
    3. Access reviews not performed (CC6)
    4. Incident response plan not tested (CC7)
    5. Change management not consistently followed (CC8)
    6. No vendor risk program (CC9)
    7. Availability SLAs not monitored or evidenced (A1)
    8. Data classification not defined (C1, P3)
    9. Privacy notice incomplete or missing (P1)

    Step 4 — Remediation Plan

    For each 🔴 or 🟡 item, output a remediation plan entry:

    Control Area: [TSC criterion, e.g., CC6.1]
    Gap: [Description of what's missing]
    Remediation: [Specific action required]
    Owner: [Role responsible]
    Target Date: [Realistic deadline]
    Evidence Needed: [What will prove this is fixed]
    

    Policy & Procedure Writing

    Read references/policies.md for full templates and writing guidance.

    Core Policy Set Required for SOC 2

    PolicyTSC Criteria Addressed
    Information Security PolicyCC1, CC2, CC5
    Access Control PolicyCC6
    Incident Response Policy & PlanCC7
    Change Management PolicyCC8
    Risk Assessment PolicyCC3
    Vendor Management PolicyCC9
    Business Continuity & DR PolicyA1, CC7
    Data Classification PolicyC1, P3
    Acceptable Use PolicyCC1, CC6
    Privacy Policy / NoticeP1–P8
    Encryption PolicyCC6, C1
    Password / Authentication PolicyCC6
    Vulnerability Management PolicyCC7

    Policy Writing Principles

    1. Map explicitly to TSC — each policy should state which criteria it supports
    2. Assign ownership — every policy needs a named owner/role
    3. Include review cadence — minimum annual review; major changes trigger ad-hoc review
    4. Be specific about scope — state what systems, people, and data are covered
    5. Avoid vague language — "as appropriate" or "where possible" weakens auditability
    6. Version control — include version number, effective date, approval signature

    Control Documentation

    Read references/controls.md for the full control matrix template and per-criterion examples.

    Control Statement Format

    Each control should be documented as:

    Control ID:    [e.g., CC6.1-001]
    TSC Criterion: [e.g., CC6.1 – Logical Access Controls]
    Control Title: [Short descriptive name]
    Control Type:  [Preventive / Detective / Corrective]
    Control Owner: [Role]
    Frequency:     [Continuous / Daily / Monthly / Annual / Event-driven]
    Description:   [What the control does and how it works]
    Evidence:      [What artifacts prove this control operates]
    Test Procedure:[How an auditor would test this]
    

    Control Types to Know

    • Preventive — stops a problem before it occurs (e.g., MFA, firewall rules)
    • Detective — identifies a problem after it occurs (e.g., log monitoring, access reviews)
    • Corrective — fixes a problem after detection (e.g., patch management, incident remediation)

    Auditors expect a mix. Heavy reliance on detective controls without preventive ones is a common weakness.


    Audit Evidence Preparation

    Read references/evidence.md for a full evidence catalog by criterion.

    Evidence Principles

    1. Contemporaneous — evidence must be created at the time the control operates, not reconstructed retroactively
    2. Complete — covers the full audit period (for Type 2)
    3. Attributable — shows who performed the action and when
    4. Consistent — demonstrates the control is repeatable, not a one-time event

    Evidence Organization

    Organize evidence in folders mirroring criteria:

    /audit-evidence/
      /CC1-control-environment/
      /CC2-communication/
      /CC3-risk-assessment/
      /CC4-monitoring/
      /CC5-control-activities/
      /CC6-access-controls/
      /CC7-system-operations/
      /CC8-change-management/
      /CC9-vendor-risk/
      /A1-availability/        (if in scope)
      /C1-confidentiality/     (if in scope)
      /PI1-processing-integrity/ (if in scope)
      /P1-P8-privacy/          (if in scope)
    

    Common Evidence Artifacts

    Control AreaTypical Evidence
    Access controlUser access list exports, provisioning tickets, access review sign-offs
    Incident responseIncident tickets, IR runbooks, tabletop exercise records
    Change managementChange request tickets, approval records, deployment logs
    Risk assessmentRisk register, risk assessment document with sign-off
    Vendor managementVendor inventory, vendor assessments, contracts with security clauses
    MonitoringSIEM alerts/dashboards, vulnerability scan reports
    AvailabilityUptime dashboards, SLA reports, DR test results
    PrivacyPrivacy impact assessments, consent records, data subject request logs

    Vendor Risk Questionnaires

    Read references/vendor.md for full questionnaire templates and review guidance.

    When to Use (CC9 Context)

    SOC 2 CC9 requires organizations to identify and manage risks from vendors and business partners. This means:

    • Maintaining a vendor inventory with risk tiering
    • Performing due diligence before onboarding critical vendors
    • Reviewing vendor SOC 2 reports (or equivalent) annually
    • Addressing Complementary User Entity Controls (CUECs) from vendor SOC 2 reports

    Vendor Risk Tiers

    TierCriteriaReview Cadence
    CriticalAccess to production data or systemsAnnual full assessment + SOC 2 report review
    HighProcess sensitive data on org's behalfAnnual questionnaire or SOC 2 review
    MediumLimited data access, operational dependencyBiannual questionnaire
    LowNo data access, low operational riskLightweight onboarding check

    Output Format Guidelines

    Adapt your output to the user's context:

    • First-time / startup — explain concepts, use plain language, provide examples, offer templates
    • Security/compliance team — use technical TSC language, jump to specifics, provide gap matrices
    • Auditor/consultant — use precise AICPA language, cite criteria codes, offer control testing procedures
    • Responding to a customer — provide concise, professional summaries suitable for sharing externally

    Always:

    • Reference TSC criteria codes (e.g., CC6.1) when making specific claims
    • Distinguish Type 1 vs Type 2 where relevant
    • Flag when something requires a licensed CPA firm (formal audit, readiness letter)
    • Note that controls must be tailored to the organization — SOC 2 prescribes criteria, not specific controls

    Reference Files

    Load these files when working on the corresponding tasks:

    • references/controls.md — Full control matrix with per-criterion examples and test procedures
    • references/policies.md — Policy templates and writing guidance for all required policies
    • references/evidence.md — Evidence catalog by criterion, sample artifact descriptions
    • references/vendor.md — Vendor risk questionnaire template and CUEC review guidance

    This skill provides general compliance information, not legal advice. Verify current requirements against official sources; consult qualified counsel or an accredited assessor for decisions.

    Frequently asked questions

    What to verify before installation and use

    What does the soc2 source document cover?

    Last verified: 2026-07-03

    How do I install soc2?

    The source record exposes this install command: npx skills add https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance --skill "plugins/soc2/skills/soc2". Inspect the command and pinned source before running it.

    Alternatives

    Compare before choosing

    Computed 99238

    enuno/unifi-mcp-server

    unifi-mcp-tool-builder

    Specialized guide for adding new MCP tools to the UniFi MCP Server following project standards, UniFi API patterns, and test-driven development practices. Use when implementing new UniFi Network Controller features as MCP tools.

    Computed 9916

    NintendaDev/unikit-ai

    unikit-docs

    Generate and maintain the project's TECHNICAL documentation from its codebase — scans the project structure, tech stack, and module boundaries, then writes a lean README landing page plus detailed topic pages (architecture, modules, setup, build, APIs), only the docs that are relevant. Use whenever the user wants to create, update, or validate documentation of the CODE or the project itself, e.g. "generate documentation", "create docs", "write the README", "update the project docs", "document th

    Computed 9880

    vasilyu1983/AI-Agents-public

    research-git

    Scans public GitHub repos for agent skills, dev practices, and code patterns. Use when enriching skills, setting team policy, or researching a build domain.

    Computed 9867

    SerendipityOneInc/ZooData-Skills

    zoodata

    API endpoint reference for the ZooData data platform: the 12 commerce endpoints plus 10 keyword-intelligence endpoints (categories, markets, products, competitors, realtime ASIN, AI review analysis, raw reviews, price band, brand, history, and the keyword detail/trend/extends/search/ market-profile/product-traffic/competitor-keywords/traffic-profile/ traffic-timeline family) — their inputs/outputs, parameter quirks, Quick Start (auth, base URL), how credits are tracked (meta.creditsConsumed), an