Gap assessment
GRC skills for Claude Code and AI agents. SOC 2, HIPAA, ISO 27001 — field-tested by Cycore Secure.
npx -y skills add cycoresecure/grc-skills --skill gap-assessmentAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
3 things to look at
- 10 days oldThe repository was created 10 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Run a SOC 2, HIPAA, or ISO 27001 gap assessment from whatever evidence the client provides: GRC platform exports (Vanta, Drata, or similar), policy documents, system screenshots, and interview notes. Produces an exhaustive, client-readable gap report with precise finding language, cross-source evidence resolution, stack-tailored remediation actions, and risk/effort ratings. Use when someone asks to "run a gap assessment", "do a readiness assessment", "where are our gaps", "analyze this compliance export", or "how ready are we for the audit".
SKILL.md
9.1 KB, as published. Nobody here has run it
Gap Assessment
Guides a consultant (or an agent acting as one) through a readiness gap assessment against SOC 2, HIPAA, or ISO 27001. The method is evidence-first: what we check, what we found, what the platform says, what it means, what to do. The GRC platform's own "Not Ready" or "Needs evidence" flag is secondary metadata, never the headline.
Step 1. Intake and inventory the evidence
List every source the user provided before analyzing any of them. Typical sources:
- GRC platform exports: controls list, personnel/people export, device or computers export, vendors export, tests or monitors export
- Policy and procedure documents
- A scoping questionnaire or interview notes (cloud provider, identity provider, MDM, source control, CI/CD, ticketing, monitoring, backup)
- Prior audit reports or auditor workpapers
Confirm the target framework(s) and the assessment boundary (which product, which environments, which entities). If a scoping questionnaire exists, parse it rather than re-asking the client for the same facts; only ask for genuine clarifications.
Personnel scope rule
When analyzing a people or personnel export, exclude two groups from every count and every finding before doing anything else:
- Ex-employees or deactivated accounts.
- External consultants. Accounts with the consulting firm's email domain belong to the assessor, not the client. Ask the user which domains are consultant domains if it is not obvious.
Report the headcount math explicitly: total records, active, consultants excluded, in-scope. A "3 of 12 people missing training" finding computed over the wrong denominator is wrong twice.
Step 2. Build the control worklist
Enumerate every control the framework or platform expects, not just the ones flagged. For each control record: control ID, control name, domain (access control, endpoint security, HR security, change management, and so on), the platform's raw status, and any linked evidence.
Step 3. Cross-source resolution (mandatory before raising anything)
A "needs evidence" or "not ready" flag in the GRC platform means no artifact was uploaded against that control. It does not mean the control is not operating. Before raising any finding, check every other provided source for corroborating data:
- Endpoint controls (anti-malware, disk encryption, screen lock, MDM coverage): check the devices/computers export field by field.
- Personnel controls (background checks, policy acknowledgment, security training): check the people export, using the in-scope filter from Step 1.
- Vendor management controls: check the vendors export.
- Policy controls: check the actual policy documents for existence, approval, owner, and review date. Verify content, not just filename.
- Architecture and configuration controls: check the scoping questionnaire and any screenshots.
Assign each flagged control one of three verdicts:
- Operating: cross-source data shows the control is running. This is not a gap. Classify it as an Opportunity for Improvement (OFI): the remaining work is uploading evidence so the platform record matches reality. Low risk, low effort, reported in its own section, never mixed into findings.
- Failing: cross-source data confirms the gap, often with specifics (for example "4 of 17 devices unencrypted"). Report it as a finding with the stronger evidence pointer, including counts and affected entities.
- Unknown: no corroborating signal in any source. Report it as a finding based on the platform status, and say plainly that no cross-source evidence was found.
Step 4. Write findings that invert the control statement
Control names describe the desired state. A finding states the negation of that desired state as observed fact. Never write "needs attention", "gap identified", or "evidence missing" as the headline.
| Control name | Finding |
|---|---|
| MFA enforced for admin console | MFA is not enforced for the admin console |
| Production asset inventory maintained | Production asset inventory is not maintained; no current inventory was evidenced |
| Security policies established and reviewed | Security policies are not established or have not been reviewed within the required cadence |
| Background checks performed for employees | Background checks have not been performed for 3 of 14 in-scope employees |
Negate the operative verb (maintained, enforced, restricted, implemented, documented, configured, encrypted, reviewed, approved, performed). For compound names, negate each clause ("not documented or not approved"). Include counts and named entities when the cross-source data provides them. If the control name has no negatable verb, fall back to "Evidence was not provided for: [control name]".
Step 5. Give every finding full depth
Each finding carries all of the following. Thin findings are the most common failure mode of gap reports; do not skip fields.
- Gap statement: the inverted control statement from Step 4.
- Why it matters: the security or audit consequence in plain language, tied to the framework requirement.
- Evidence observed: what was actually checked and found, source by source, including the cross-source verdict and the raw platform status.
- Remediation actions: numbered, tailored to the client's actual stack from the scoping data ("enable full-disk encryption via your MDM on the 4 unencrypted devices", not "implement encryption"). Every action must name the evidence artifact that will be produced and the test or check that will verify closure.
- Expected auditor pushback: what the auditor will probe when sampling this control, and what a defensible answer looks like.
- Risk rating (1 to 5) and effort rating (1 to 5).
Risk scale
- Low: minor hygiene, no audit consequence.
- Medium-Low: isolated gap, contained blast radius.
- Medium: pattern gap; the auditor will sample and an exception is likely.
- High: material security or compliance exposure.
- Critical: disqualifying for the audit without immediate remediation.
Effort scale
- Trivial: a day or less, usually uploading existing evidence.
- Small: 1 to 3 days, configure or document an existing capability.
- Medium: 1 to 2 weeks, standard implementation work.
- Large: 2 to 4 weeks, new control requiring tooling or process change.
- Major: a month or more, program-level work.
When the cross-source verdict is Operating, drop risk to 1 or 2 and effort to 1: the remaining work is an evidence upload. A confirmed Failing verdict holds or raises the baseline risk.
Step 6. Assemble the report
The report must be exhaustive (every flagged control accounted for, none silently dropped) and readable by a non-technical client. Structure:
- Executive summary: lead with the five highest-risk gaps in plain language, then overall readiness posture, then the headline numbers (controls reviewed, findings, OFIs, breakdown by risk).
- Scope and sources: what was assessed, which sources were provided, the personnel scope math from Step 1.
- Priority findings: table grouped by domain. Columns: control ID, finding (gap statement), top remediation actions, risk, effort.
- Opportunities for Improvement: controls proven operating by cross-source evidence where only the platform record needs aligning. Keep this section separate so real gaps are not diluted.
- Recommended remediation plan: sequenced by risk then effort; quick wins (high risk, low effort) first.
- Assessment approach: one page on method, including the cross-source resolution rule, so the client understands why some platform flags did not become findings.
- Appendix: finding details: the full six-field entry from Step 5 for every finding rated risk 3 or higher.
Step 7. Quality check before delivery
- Every finding headline is an inverted control statement, not a vague flag.
- Every "needs evidence" item was cross-resolved against all sources; the verdict is stated in the finding.
- Consultant accounts are excluded from all personnel counts.
- Every remediation action names an evidence artifact and a verifying test.
- No invented facts: every claim traces to a provided source. If a source was not provided, say "not evidenced in the materials provided", never assume.
- Counts in the executive summary match the tables.
- No client-confidential detail from one engagement appears in another client's report.