Purpose
Turn a raw enterprise security or compliance requirement set into a decision-ready mapping — every requirement scored against current product capability, classified by deal risk, and paired with either an approved sales answer or a specific engineering commitment. Eliminates the manual back-and-forth between Sales, Product, and Security that stalls enterprise deals in procurement.
When to Use
Invoke this skill when the user asks to:
- Respond to an enterprise security questionnaire (SIG, CAIQ, or a custom vendor form)
- Map the security or compliance section of an RFP to product capabilities
- Assess whether the product meets a prospect's SOC 2, ISO 27001, HIPAA, or GDPR requirements
- Prepare answers for a vendor risk assessment or third-party security review
- Identify capability gaps that could block or delay an enterprise deal
- Turn compliance gaps into a prioritized engineering backlog
Inputs Required
Before starting, collect:
- Requirement source: The questionnaire, RFP section, or requirement list (pasted text, structured list, or summary)
- Product capability inventory: What the product currently supports for security/compliance (SSO, RBAC, encryption, audit logs, data residency, certifications held, etc.)
- Roadmap items: Any planned or in-progress capabilities and rough timelines
- Deal context: Deal size, target close date, and how strategic the account is
- Frameworks in scope: Which standards the prospect cares about (SOC 2, ISO 27001, HIPAA, GDPR, FedRAMP, PCI-DSS, etc.)
- Data handled: What customer data the product touches (PII, PHI, financial, none)
- Escalation owners: Who owns Security, Product, and Legal answers (used to route open items)
If roadmap items or escalation owners are missing, map against current capability only and flag routing decisions as "owner TBD."
Instructions
Step 1: Normalize and Categorize Requirements
Parse the source into discrete, atomic requirements. Split compound requirements ("data is encrypted at rest and in transit and access is logged") into separate line items so each can be scored independently.
Assign each requirement to one governance domain:
- Access & Identity (SSO, SAML/SCIM, MFA, RBAC, least privilege, session management)
- Data Protection (encryption at rest/in transit, key management, data residency, retention/deletion)
- Audit & Monitoring (audit logs, log retention, SIEM export, anomaly detection)
- Certifications & Attestations (SOC 2 Type II, ISO 27001, penetration test reports, BAA/DPA availability)
- Infrastructure & Availability (uptime SLA, DR/BCP, backup, tenant isolation)
- Vendor & Subprocessor Management (subprocessor list, fourth-party risk, breach notification terms)
- Privacy & Legal (GDPR/CCPA rights handling, DPA terms, cross-border transfer mechanisms)
Step 2: Score Each Requirement Against Capability
For every requirement, assign one status:
- Met — product fully satisfies it today; a defensible answer exists
- Partial — satisfied with caveats, on a higher tier, or via configuration
- Roadmap — not available now but planned; include the rough timeline
- Gap — not available and not planned
- N/A — does not apply given the data handled or deployment model
Never mark Met without a concrete supporting fact (feature name, certification, config path). If the supporting fact isn't in the inputs, downgrade to Partial and flag for verification.
Step 3: Classify Deal Risk
For each Partial, Roadmap, and Gap item, assign a deal-risk level:
- Blocker — a hard requirement the prospect will not waive (e.g., "must be SOC 2 Type II" for a regulated buyer)
- Negotiable — likely acceptable with a compensating control, contractual commitment, or roadmap date
- Cosmetic — a checkbox item unlikely to affect the decision
Weight blockers against the deal context: a single blocker on a strategic, large deal warrants escalation; the same blocker on a small deal may not be worth the engineering cost.
Step 4: Draft Response Language
For each requirement, produce the sales-ready answer:
- Met → a direct, confident affirmative answer with the supporting fact named
- Partial → an honest answer that states what is supported and the compensating control or tier path — no overclaiming
- Roadmap → a forward-looking answer with a timeframe and a suggested contractual mechanism (roadmap commitment letter, phased rollout)
- Gap → a truthful non-availability answer plus the compensating control or workaround, if any
Answers must be written in language a Solutions Engineer can paste directly into a questionnaire. No internal jargon, no hedging that reads as evasive.
Step 5: Generate the Engineering Backlog
Convert every Partial, Roadmap, and Gap into a ticket-ready entry:
- Requirement it satisfies
- Governance domain
- Deal-risk level (and which deal it's blocking)
- Suggested scope (one-line acceptance criterion)
- Priority (derived from deal-risk × deal strategic value)
Step 6: Summarize the Deal Position
Produce a one-paragraph verdict: can this deal proceed as-is, does it need a negotiated exception, or does it require engineering work before closing? State the specific blockers by name and the recommended path.
Output Format
- Structure: A requirement matrix table, followed by the response-language section, the engineering backlog, and the deal-position verdict
- Length: 1,000–1,500 words depending on requirement count
- Format: Requirement matrix as a table (Requirement | Domain | Status | Deal Risk | Supporting Fact); response language and backlog as structured lists; verdict as prose
- Sections: Requirement Matrix → Response Language → Engineering Backlog → Deal Position Verdict
- Tone: Precise and truthful — a specialist who protects the deal by never overstating capability; confident where the product wins, honest where it doesn't
Quality Checklist
Before delivering output, verify:
- [ ] Every requirement in the matrix has a status AND a deal-risk level (except N/A items)
- [ ] No requirement is marked "Met" without a named supporting fact
- [ ] Compound requirements were split into atomic line items
- [ ] Every Partial, Roadmap, and Gap appears in the engineering backlog with a priority
- [ ] Response language is paste-ready — no placeholders, no internal jargon
- [ ] The verdict names specific blockers rather than giving a vague "mostly ready"
Notes
- The most common failure in enterprise deals is a Solutions Engineer marking a Partial as fully Met — it surfaces later in the security review and damages trust. Bias toward honest Partial classifications.
- When a certification (SOC 2 Type II, ISO 27001) is a stated Blocker and the product doesn't hold it, no compensating control substitutes — escalate immediately rather than drafting a workaround answer.
- Roadmap answers are only credible with a date and a contractual mechanism; a vague "it's on our roadmap" reads as a soft no to procurement teams.
- Data-handling context drives N/A decisions: if the product touches no PHI, HIPAA/BAA requirements are legitimately N/A, not gaps.
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