--- name: security-policy-drafter description: Writes complete security policy documents (acceptable use, password, BYOD, remote work, incident response policy, data classification) from a plain-English brief. version: 1.0.0 author: VantagePoint Networks audience: IT Managers, Information Security Leads, Compliance Managers, HR Partners output_format: Formatted Markdown policy document with purpose, scope, definitions, requirements, exceptions, enforcement, review cycle, and change log. license: MIT --- # Security Policy Drafter Writes the policy document you've been putting off. Produces a governance-ready document with the structure auditors expect and language staff can actually understand. ## How to use this skill 1. Download this `SKILL.md` file. 2. Place it in `~/.claude/commands/` (macOS/Linux) or `%USERPROFILE%\.claude\commands\` (Windows). 3. Run `/security-policy-drafter` in Claude Code. Describe the policy you need and what your environment looks like. Answer clarifying questions. Receive the draft. ## When to use this - You need an Acceptable Use Policy and the last one you had was a 2014 word doc. - You're aligning to ISO 27001 / SOC 2 / Cyber Essentials and need a policy set to reference. - An auditor has asked "where is your BYOD policy?" and you need to answer tomorrow. - You've rolled out a new technology (cloud, remote work, AI tools) that doesn't fit existing policies. - You want a policy template set you can reuse with minor adjustments across multiple policies. ## Policies this skill can draft - Acceptable Use Policy - Password / Authentication Policy - BYOD / Mobile Device Policy - Remote / Hybrid Working Policy - Information Classification Policy - Incident Response Policy - Change Management Policy - Access Control Policy - Encryption Policy - Vendor / Third-Party Risk Policy - Data Protection / GDPR Policy - AI / Generative Tools Acceptable Use - Clean Desk / Physical Security Policy - Backup & Recovery Policy - Vulnerability Management Policy ## What you'll get - **Cover page metadata** - version, owner, approver, approval date, review date, classification. - **Purpose** - why this policy exists. - **Scope** - who it applies to (employees, contractors, partners, visitors), which systems, which data. - **Definitions** - so the document doesn't ambiguate key terms. - **Policy requirements** - the substance, in numbered, testable statements. - **Exceptions** - the process for requesting, approving, tracking exceptions. - **Roles & responsibilities** - who enforces, who complies, who approves. - **Enforcement** - consequences of non-compliance, linked disciplinary process. - **Review cycle** - annual or bi-annual, with named reviewer. - **Related documents** - standards, procedures, other policies. - **Change log** - version history. - **Communication plan** - how staff learn about the policy (induction, annual refresher, channel). ## Clarifying questions I will ask you 1. **Which policy do you want?** (From the list above, or describe) 2. **Who is the audience?** (All staff / technical staff only / specific group) 3. **What's your organisation size and type?** (Drives tone and example specifics - 50-person startup vs 5000-person bank) 4. **Jurisdiction(s)?** (UK / EU / US / multi - affects data protection, surveillance, employment law hooks) 5. **What compliance framework drives this?** (ISO 27001 A.X.Y / SOC 2 CC / Cyber Essentials / PCI-DSS / internal baseline) 6. **Existing related policies?** (So this one refers out, not overlaps) 7. **What's your environment reality?** (Cloud-first / on-prem / hybrid / BYOD common / strictly corporate devices) 8. **Tone preference?** (Formal / plain-English / mixed) 9. **Who owns this policy?** (Named role - typically CISO, Head of IT, DPO) 10. **Who approves?** (Board / Exec / CEO / IT Director) 11. **Any specific prohibited / required behaviours to include?** (e.g. "generative AI use must be disclosed in code reviews") 12. **What's the review cadence?** (Annual is standard; high-change areas quarterly) ## Output template ```markdown # **Document ID:** POL-- **Classification:** Internal Use **Version:** X.X **Owner:** **Approver:** **Approved:** YYYY-MM-DD **Effective:** YYYY-MM-DD **Next review:** YYYY-MM-DD **Supersedes:** ## 1. Purpose ## 2. Scope ### Who this applies to - All employees of - Contractors, consultants, and agency staff with access to - ### What this applies to - All - All devices (corporate-owned and personal) used to access the above - ### What is explicitly out of scope - - ## 3. Definitions | Term | Definition (within this policy) | |---|---| | | | | | | ## 4. Policy Statements ### 4.1 - 4.1.1 - 4.1.2 - 4.1.3 ### 4.2 - 4.2.1 <> - 4.2.2 <> ### Universally: what is NEVER permitted - - - ## 5. Exceptions ### How to request an exception 1. Submit a to including: business justification, scope, duration, compensating controls. 2. Review by within working days. 3. Decision: Approved / Conditionally Approved / Rejected - documented and communicated to requester. 4. Exceptions recorded in the Exception Register with . ### Exceptions that CANNOT be granted - - ## 6. Roles & Responsibilities | Role | Responsibility | |---|---| | All in-scope personnel | Comply with this policy; report suspected violations | | Line managers | Ensure team members are aware; address violations in their teams | | | Own, review, update the policy; approve exceptions | | | Approve the policy; chair annual review | | IT / Security function | Implement technical controls; monitor compliance; investigate violations | | HR | Integrate with induction; support disciplinary action where needed | | Legal / DPO | Advise on legal and regulatory implications | ## 7. Enforcement - Suspected violations investigated by in consultation with HR and (if applicable) Legal. - Proportionate action taken in line with . Depending on severity, action may range from additional training to termination of employment or contract. - Where violation involves potential criminal conduct, . - Non-compliance findings are tracked and reported to via the quarterly compliance report. ## 8. Related Documents - - - - ## 9. Communication & Awareness - **On joining:** Policy included in induction. Written acknowledgement required. - **Annually:** Refresh training; attestation of policy awareness. - **On change:** Material changes communicated to all in-scope personnel via within working days of approval. - **Reference location:** ## 10. Review Cycle - Scheduled review: annually, by . - Trigger-based review: following material incident, change in legislation / framework, or significant organisational change. - Minor updates (typos, clarifications): tracked in change log, do not require re-approval. - Major updates (requirement changes, scope changes): require re-approval by . ## 11. Change Log | Version | Date | Author | Change summary | Approved by | |---|---|---|---|---| | 1.0 | YYYY-MM-DD | | Initial version | | ## 12. Approval > This policy has been approved by and is effective from . All in-scope personnel are required to comply. Questions regarding interpretation should be directed to . > > > > > ``` ## Example invocation **User:** "/security-policy-drafter - we need a Generative AI Acceptable Use policy. ~200 staff, UK-based SaaS company, ISO 27001 certified, we use Claude, Copilot, ChatGPT. Want to be permissive but avoid customer data going into prompts." **What the skill will do:** 1. Ask which tools are sanctioned, whether customer data is ever permitted (usually: never, unless using an enterprise tenant with DPA), whether code generated by AI requires disclosure, and how personal/sensitive data is defined. 2. Draft sections 4 (policy statements) with specific prohibitions (no customer data, no PII, no secrets in prompts), permissions (sanctioned tools, general-purpose coding help, drafting), and disclosure requirements (AI-authored code tagged in commits, AI-authored customer comms reviewed by a human). 3. Include enforcement that references the existing disciplinary procedure without redefining it. 4. Provide a 60-second communication plan: pin to intranet, 15-min company-all-hands walkthrough, mandatory acknowledgement at next login. ## Notes for the requester - **Policy is not procedure.** A policy says "users must use MFA on all accounts." A procedure says "to enable MFA in Okta, go to..." Keep them separate documents. - **Requirements must be testable.** "Users will protect data appropriately" is unenforceable. "Users must not store customer PII on removable media" is testable. - **Scope creep kills policies.** If a policy is 30 pages, it's probably three policies. Split. - **Name the owner, not the team.** "The IT team owns this policy" = nobody owns it. "The CISO owns this policy" = someone does. - **Exceptions are not failures.** A policy with no exception process breeds shadow compliance. A mature policy has a documented exception flow. - **"Good" looks like:** a new joiner reads the policy in 10 minutes and can tell you what they must, must not, and can ask about doing. An auditor maps it cleanly to the control they're testing.