Purpose
Map a single described control to the specific clauses, functions, and requirements it touches across one or more frameworks, then classify coverage as Satisfied, Partially Satisfied, or Unaddressed — so a compliance team can pinpoint exactly where a control falls short before an auditor does. Turns "we have a control for that" into a defensible, requirement-level coverage statement.
When to Use
Invoke this skill when the user asks to:
- Map an existing control to NIST CSF, ISO 27001, SOX, GDPR, HIPAA, or PCI-DSS requirements
- Check whether a specific control satisfies a regulatory obligation
- Run a rapid gap check on an individual control before an audit
- Build a control-to-framework crosswalk or update a control matrix
- Determine which framework requirements a planned control will and won't address
- Identify evidence gaps for a control already claimed as "in place"
Inputs Required
Before starting, collect:
- Control description: What the control does, in 2–5 sentences — the activity, mechanism, or safeguard
- Control type: Preventive / Detective / Corrective / Administrative (if unknown, infer and note)
- Implementation status: Designed / Partially implemented / Fully operating
- Frameworks to map against: One or more of NIST CSF, ISO 27001, SOX, GDPR, HIPAA, PCI-DSS
- Evidence available: What documentation, logs, or artifacts back the control (policies, screenshots, configs, tickets)
- Scope/system: What system, data type, or business process the control protects
- Automation level: Manual / Semi-automated / Automated (affects testability and reliability)
If frameworks aren't specified, ask which apply. If evidence isn't described, classify based on the control as stated and flag every requirement as evidence-unverified.
Instructions
Step 1: Normalize the Control
Restate the control in standard GRC terms before mapping:
- Control objective: The risk it's intended to reduce (one sentence)
- Control activity: The concrete action performed
- Frequency: Continuous / Daily / Periodic / Event-driven
- Owner type: System-enforced vs. human-performed
- Testability: Can compliance prove it operated? (yes / partial / no)
A control that cannot be tested cannot be classified as Satisfied regardless of design quality — note this early.
Step 2: Map to Each Selected Framework
For every framework chosen, identify the specific requirement IDs the control touches. Use real identifiers, not generic descriptions:
- NIST CSF: Function → Category → Subcategory (e.g., PR.AC-1, DE.CM-3)
- ISO 27001: Annex A control numbers (e.g., A.9.2.1, A.12.4.1) and relevant clause references
- SOX: Map to ITGC domain (Access, Change Management, Operations) and the relevant assertion (completeness, accuracy, validity, restricted access)
- GDPR: Article and principle (e.g., Art. 32 security of processing, Art. 25 data protection by design)
- HIPAA: Safeguard category and citation (e.g., §164.312(a)(1) Access Control, §164.308(a)(1) Security Management)
- PCI-DSS: Requirement and sub-requirement number (e.g., Req 8.2.3, Req 10.2.1)
For each mapped requirement, capture the requirement's intent in one phrase so the classification is grounded.
Step 3: Classify Coverage per Requirement
Assign each mapped requirement one status using these criteria:
- Satisfied — The control fully addresses the requirement's intent AND testable evidence exists to prove operation. No material gap in scope, frequency, or coverage.
- Partially Satisfied — The control addresses the requirement's intent but has a gap: incomplete scope (covers some systems/data, not all), insufficient frequency, design without operating evidence, or missing a sub-requirement.
- Unaddressed — The requirement was mapped as relevant to this control's domain but the control as described does not cover it. (This surfaces obligations the team assumed were covered.)
For every Partially Satisfied and Unaddressed item, state the specific gap — not "needs improvement" but the precise missing element (e.g., "covers production servers but not the DR environment").
Step 4: Identify Evidence Gaps
For Satisfied and Partially Satisfied items, specify what evidence an auditor would expect:
- The artifact type (config export, access review log, signed policy, ticket trail)
- The retention/recency expectation (e.g., 12 months of quarterly access reviews)
- Whether the described evidence meets that bar or falls short
Step 5: Remediation Actions
For each Partially Satisfied and Unaddressed requirement, give one concrete remediation action ranked by effort vs. compliance impact:
- The specific change to the control or evidence
- Effort: Low / Medium / High
- Whether it closes a gap fully or just upgrades the status one level
Step 6: Coverage Summary
Produce a one-line verdict per framework: how many requirements were mapped and the Satisfied / Partial / Unaddressed split, plus the single highest-priority gap to close.
Output Format
- Structure: Normalized control summary → per-framework mapping tables → evidence gap notes → ranked remediation list → coverage summary
- Length: 700–1,100 words depending on framework count
- Format: Mapping presented as tables (Requirement ID | Requirement Intent | Status | Gap); remediation as a ranked list
- Sections: Normalized Control → Framework Mappings (one table per framework) → Evidence Gaps → Remediation Actions → Coverage Summary
- Tone: GRC specialist — precise, citation-grounded, audit-defensible; no hedging on status calls
Quality Checklist
Before delivering output, verify:
- [ ] Every mapped requirement uses a real framework identifier (e.g., A.9.2.1, PR.AC-1, §164.312(a)(1)) — not a paraphrase
- [ ] Every requirement has exactly one status: Satisfied, Partially Satisfied, or Unaddressed
- [ ] Each Partial and Unaddressed item names the specific gap, not a vague shortfall
- [ ] No requirement is marked Satisfied without a stated testable evidence basis
- [ ] Each gap has a remediation action with an effort rating
- [ ] Coverage summary gives a numeric Satisfied/Partial/Unaddressed split per framework
Notes
- A common error is marking design-only controls as Satisfied — without operating evidence, the ceiling is Partially Satisfied. Hold that line.
- One control rarely maps cleanly to one requirement; map the full set it touches, even partially, so assumed coverage gets tested.
- When a control spans multiple frameworks, the same gap (e.g., missing DR scope) often recurs — call it out once and reference it across mappings.
- This skill evaluates a single control in isolation. Requirements needing multiple coordinated controls should be flagged as "requires complementary control" rather than Unaddressed.
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills