Soc2

Security controls evidence, policies, and audit readiness. Use when preparing SOC2-style programs.

Security Scan

The skill is an instruction-only SOC 2 guidance workflow and its requested resources and instructions are consistent with that purpose.

Purpose & Capability

Name/description describe SOC 2 program guidance and the SKILL.md contains only procedural stages, checklists, and prompting guidance — no unrelated credentials, binaries, or system access are requested.

Instruction Scope

Instructions stay on-topic: they ask the agent to clarify context, propose a four-stage workflow, request user context, and provide checklists and failure modes. No instructions read files, access environment variables, invoke external endpoints, or collect unrelated system data.

Install Mechanism

There is no install spec and no code files — the skill is instruction-only, which minimizes disk writes and runtime risk.

Credentials

The skill declares no required environment variables, credentials, or config paths; that is proportional for a compliance-advice workflow.

Persistence & Privilege

Skill is not always-on and does not request special privileges or modifications to other skills or system configuration. Autonomous invocation is allowed by default but this is expected for user-invocable skills and is not combined with other red flags.

Assessment

This skill is a template-style SOC 2 workflow and appears safe to install from a permissions perspective. Remember: it provides guidance, not legal or audit authority — verify recommendations with your compliance team and auditors before acting. Do not paste real credentials or sensitive logs into the chat; supply only the contextual information needed (scope, systems, deadlines). If you require executable checks, integrations, or scripts to collect evidence, prefer vetted tools and explicit auth flows rather than pasting tokens into the skill.

Structured guidance for SOC 2-style programs (controls, evidence, audit readiness): confirm triggers, propose the stages below, and adapt if the user wants a lighter pass.

When to Offer This Workflow

Trigger conditions:

• User mentions compliance soc2 or closely related work
• They want a structured workflow rather than ad-hoc tips
• They are preparing a review, rollout, or stakeholder communication

Initial offer: Explain the four stages briefly and ask whether to follow this workflow or work freeform. If they decline, continue in their preferred style.

Workflow Stages

Stage 1: Clarify context & goals

Anchor on control mapping. Ask what success looks like, constraints, and what must not break. Capture unknowns early.

Stage 2: Design or plan the approach

Translate goals into a concrete plan around evidence collection. Compare alternatives and explicit trade-offs; avoid implicit assumptions.

Stage 3: Implement, validate, and harden

Execute with verification loops tied to access reviews. Prefer small steps, measurable checks, and rollback points where risk is high.

Stage 4: Operate, communicate, and iterate

Close the loop with continuous monitoring: monitoring, documentation, stakeholder updates, and lessons learned for the next cycle.

Checklist Before Completion

• Goals and constraints are explicit for SOC 2 readiness
• Risks and trade-offs are stated, not hand-waved
• Verification steps match the change’s impact (tests, canary, peer review)
• Operational follow-through is covered (monitoring, docs, owners)

Tips for Effective Guidance

• Be procedural: stage-by-stage, with clear exit criteria
• Ask for missing context (environment, scale, deadlines) before prescribing
• Prefer checklists and concrete examples over generic platitudes
• If the user declines the workflow, switch to freeform help without lecturing

Handling Deviations

• If the user wants to skip a stage: confirm and continue with what they need.
• If context is missing: ask targeted questions before strong recommendations.
• Prefer concrete examples, trade-offs, and verification steps over generic advice.

Quality Bar

• Each recommendation should be actionable (what to do next).
• Call out failure modes relevant to SOC 2 programs (security, scale, UX, or ops).
• Keep tone direct and respectful of the user’s time.