A collection of AI prompts and templates for generating security compliance documentation, with a focus on SOC 2 System Descriptions and Incident Reports.
soc2-system-desc-writer.txt(800 lines)- Comprehensive AI prompt for generating SOC 2 system descriptions
- Structured YAML input schema for systematic information gathering
- 10-part output structure (8 required + 2 optional sections)
- Built-in quality checks, guardrails, and common pitfalls guide
- Explicit TSC mapping requirements and control statement templates
- Report parameters section (Type I/II, TSC scope, carve-out vs. inclusive)
- Control statement templates with good/bad examples
- Revision checklists and validation criteria
-
soc2-system-desc-sample-input.yaml(690 lines)- Comprehensive YAML template with fictional company "Acme Software Inc."
- Realistic SaaS platform scenario with complete details
- Covers all sections: company info, infrastructure, security ops, data, governance
- Shows proper formatting for subservice organizations, controls summary, and CUECs
- Demonstrates how to specify frequencies, owners, and TSC mappings
- Use as a template for your own SOC 2 system descriptions
-
soc2-system-desc-info-gathering-checklist.md(496 lines)- Essential pre-work checklist for collecting information before writing
- Organized by topic: company info, infrastructure, security operations, data, governance
- 200+ specific questions to ask stakeholders
- Identifies which documents to request (policies, diagrams, reports)
- Lists key stakeholders to interview
- Includes tips for effective information gathering
- Start here before using the prompt
ir-report-writer.txt(145 lines)- AI prompt for generating cybersecurity incident reports
- Follows NIST Incident Response Lifecycle framework
- Structured 6-part report format (Executive Summary, Details, Impact, Root Cause, Response, Recommendations)
- Includes methodology for systematic incident analysis
- Professional tone guidelines for technical and executive audiences
# Start with the checklist
open soc2-system-desc-info-gathering-checklist.md- Conduct stakeholder interviews (CISO, CTO, DevOps Lead, IT Manager, Compliance Manager)
- Request policies, diagrams, and assessment reports
- Document specific frequencies, thresholds, and SLAs
- Use the checklist to ensure nothing is missed
# Copy the sample as a starting point
cp soc2-system-desc-sample-input.yaml your-company-input.yaml- Fill in your company's specific information
- Use
[PLACEHOLDER: description]for unknowns - Be specific about frequencies ("quarterly" not "regularly")
- Include actual numbers, timelines, and tool names
- Use
soc2-system-desc-writer.txtas your AI prompt - Paste your YAML input at the bottom where indicated
- Attach supporting documents (policies, diagrams) if available
- Review output for placeholders and quality
- Address all
[PLACEHOLDER]tags by gathering missing information - Review with stakeholders for accuracy
- Validate control statements are testable and verifiable
- Share early draft with auditor for feedback
- Update YAML and regenerate as needed
- Gather logs, alerts, and forensic evidence
- Document timeline of events
- Identify affected systems and impact
- Collect any preliminary investigation findings
- Use
ir-report-writer.txtas your prompt - Fill in business context (services, location, compliance obligations)
- Provide incident details and evidence
- Review output for completeness and accuracy
- Comprehensive data model covering all system description requirements
- Pre-defined fields for company, infrastructure, security, data, governance
- Built-in placeholders system for tracking missing information
- Easy to update incrementally as you gather more details
- Supports complex scenarios (multiple subservices, AI providers, cloud-native)
Explicitly define upfront:
- Report Type: Type I (design) or Type II (design + operations)
- TSC in Scope: Security (required) + optional Availability, Processing Integrity, Confidentiality, Privacy
- Subservice Method: Carve-out (typical) or Inclusive
- Audit Period: Date range for Type II audits
The prompt generates a complete system description with:
- Company Overview and Services Provided
- System Boundaries (in-scope and out-of-scope)
- Subservice Organizations
- Principal Service Commitments and System Requirements
- System Components (Infrastructure, Software, People, Data, Policies)
- Internal Controls (Environment, Risk, Communication, Monitoring, Activities)
- Complementary Subservice Organization Controls (CSOCs)
- Complementary User Entity Controls (CUECs)
- Disclosures (optional - incidents, significant changes)
- Criteria Not Relevant (optional - TSC not applicable)
- Revision and quality check checklists
- Common pitfalls with ❌/✅ examples
- Toggles and guardrails to prevent errors
- TSC mapping requirements and validation
- Control statement templates with good/bad examples
- Consistency checks across sections
- Handles multiple AI service providers (Anthropic, OpenAI, etc.)
- Cloud-native infrastructure (AWS, Azure, GCP)
- API-first and serverless architectures
- Event-driven systems
- Multiple subservice organizations with different attestation types
- Start Early: Allow 2-4 weeks for comprehensive information gathering
- Interview Key Stakeholders: CISO, CTO, DevOps Lead, IT Manager, Compliance Manager, Legal
- Request Evidence: Don't just ask what they do - ask to see logs, screenshots, tickets, or reports
- Be Specific: Push for exact frequencies, thresholds, and timelines (not "regularly" or "promptly")
- Cross-Reference: Verify information consistency across stakeholders and documents
- Document Gaps: Use
[PLACEHOLDER]tags to track missing information
- Avoid Marketing Language: No "best-in-class," "cutting-edge," "world-class," or superlatives
- Be Precise: "Quarterly" not "regularly," "within 24 hours" not "promptly," "7 days" not "quickly"
- Write Testable Controls: Specify who does what, when, how, and with what tools
- Third Person: "[Company Name] implements..." not "We implement..."
- Present Tense Only: Only describe controls currently implemented, not planned or aspirational
- Specific Numbers: Include actual frequencies, SLAs, thresholds, retention periods, team sizes
- Share Early Drafts: Get auditor feedback before finalizing to avoid rework
- Flag Uncertainties: Better to have placeholders than incorrect statements
- Document Evidence: Note where evidence exists for each control (logs, tickets, reports)
- Maintain Consistency: Use same terminology throughout document
- Map to TSC: Explicitly map every control to applicable Trust Services Criteria
- Support Commitments: Ensure service commitments align with actual capabilities
Security (CC - Common Criteria) - Always required:
- CC1: Control Environment
- CC2: Communication and Information
- CC3: Risk Assessment
- CC4: Monitoring Activities
- CC5: Control Activities
- CC6: Logical and Physical Access Controls
- CC7: System Operations
- CC8: Change Management
- CC9: Risk Mitigation
Choose based on your services and customer requirements:
- Availability (A) - System availability, uptime SLAs, and recovery capabilities
- Processing Integrity (PI) - Data processing accuracy, completeness, and timeliness
- Confidentiality (C) - Protection of confidential information beyond general security
- Privacy (P) - Privacy practices and compliance (GDPR, CCPA, HIPAA, etc.)
Most organizations choose: Security + Availability as the baseline.
prompts-sec-comp/
├── README.md # This file
├── ir-report-writer.txt # Incident report prompt
├── soc2-system-desc-writer.txt # Main SOC 2 prompt
├── soc2-system-desc-sample-input.yaml # YAML template with examples
└── soc2-system-desc-info-gathering-checklist.md # Pre-work checklist
The YAML input captures all information needed for the system description:
- Basic company information
- Services in scope
- Business model and customers
- In-scope: applications, infrastructure, people, procedures, data
- Out-of-scope: explicit exclusions
- Audit period (Type II)
- Cloud providers and services
- Technology stack (software, tools, platforms)
- Network architecture and segmentation
- Environments and isolation
- Identity and access management
- Security monitoring and logging
- Vulnerability and patch management
- Incident response procedures
- Penetration testing
- Data types and classification
- Data flows and storage
- Encryption (in-transit and at-rest)
- Retention and disposal
- Backup and recovery (RTO/RPO)
- Organizational structure and oversight
- Policy framework
- Risk management methodology
- Compliance monitoring
- Training programs
- Security commitments
- Availability commitments (SLAs)
- Processing integrity commitments
- Confidentiality commitments
- Privacy commitments
- Controls summary (with frequency, owner, TSC mapping)
- Subservice organizations (with CSOCs)
- Complementary user entity controls (CUECs)
- Disclosures (incidents, changes)
- "We have strong security controls" → Too vague
- "Access is reviewed regularly" → What's "regularly"?
- "We will implement MFA" → Don't describe future plans
- "Best-in-class security practices" → Marketing language
- "We monitor our systems" → First person
- Inconsistent terminology across sections
- Missing TSC mappings for controls
- Describing controls not actually implemented
- "User access reviews conducted quarterly by IT Manager with department head approval"
- "Multi-factor authentication required for all administrative access via Okta"
- "[Company Name] monitors production systems 24/7 via Datadog with 15-minute alert response SLA"
- Specific frequencies, tools, roles, and processes
- Third person throughout
- Consistent terminology
- Every control mapped to TSC
- Only document implemented controls with evidence
- Secureframe: How to Write a SOC 2 System Description
- AICPA Trust Services Criteria (TSC)
- NIST Risk Management Framework (RMF)
- NIST Incident Response Lifecycle
- ISO 27001 Standard (complementary)
- AICPA SOC 2 Reporting Framework - Official SOC 2 guidance
- NIST Cybersecurity Framework (CSF) - Risk-based security framework
- CIS Controls - Prioritized security best practices
- ISO 27001 - Information security management standard
Consider using GRC platforms to streamline compliance:
- Vanta, Drata, Secureframe - Compliance automation
- Jira, ServiceNow - Ticketing and change management
- Confluence, Notion - Policy documentation
- GitHub, GitLab - Version control and CI/CD
This is a working repository for security compliance prompt development.
- Test with Real Data: Use anonymized real-world examples to validate
- Document Changes: Explain why changes improve output quality
- Maintain Clarity: Keep instructions clear and examples specific
- Update README: Document new files and update usage instructions
- Version Thoughtfully: Significant changes warrant version updates
- Additional compliance framework prompts (ISO 27001, HIPAA, PCI DSS)
- Enhanced examples for specific industries
- Additional checklists and templates
- Improved YAML schema sections
- Real-world case studies and usage patterns
- Add diagram generation guidance (Mermaid syntax for architecture diagrams)
- Include sample control testing procedures
- Add evidence collection checklist aligned with controls
- Create pre-audit readiness assessment template
- ISO 27001 Statement of Applicability (SoA) prompt
- Risk Assessment Report generator
- Business Continuity/Disaster Recovery Plan prompt
- Policy Template Generator (dynamic policy creation)
- HIPAA Security Rule documentation prompt
- PCI DSS Self-Assessment Questionnaire (SAQ) prompt
- NIST CSF assessment and gap analysis prompt
- Control Testing Procedure generator
- Vendor security assessment questionnaire generator
- Security awareness training content generator
These prompts are tools to assist in documentation preparation. They do NOT replace:
- ❌ Professional security expertise and experience
- ❌ Qualified SOC 2 auditors and attestation services
- ❌ Legal and compliance counsel
- ❌ Actual implementation of security controls
- ❌ Ongoing security operations and monitoring
- Review Required: Always have system descriptions reviewed by internal stakeholders, legal/compliance teams, and your SOC 2 auditor before finalization
- Accuracy Critical: You are responsible for the accuracy of information provided to the prompt and generated in the output
- Evidence Needed: Having a well-written system description doesn't mean controls are operating effectively - auditors will test with evidence
- Living Document: System descriptions should be updated as your systems, controls, and organization evolve
- Review the sample YAML (
soc2-system-desc-sample-input.yaml) for formatting examples - Use the checklist (
soc2-system-desc-info-gathering-checklist.md) to ensure complete information gathering - Check the prompt (
soc2-system-desc-writer.txt) for built-in guidance and examples - Validate output against the quality checklist included in the prompt
Q: Do I need to provide policy documents?
A: Helpful but not required. The YAML schema captures procedural details. Policies can validate and enrich during iteration.
Q: How long does information gathering take?
A: Typically 2-4 weeks for a comprehensive first-time SOC 2. Faster for renewals.
Q: Can I use this for SOC 2 Type I and Type II?
A: Yes! Specify the report type in the YAML report_parameters section.
Q: What if I don't know some information?
A: Use [PLACEHOLDER: description] in the YAML. The prompt will flag these for follow-up.
Q: How do I handle multiple cloud providers or AI services?
A: The YAML schema supports multiple subservice organizations with individual CSOCs.
- ✅ Initial repository creation
- ✅ SOC 2 System Description prompt with YAML input schema
- ✅ Comprehensive sample YAML input (690 lines)
- ✅ Information gathering checklist (496 lines)
- ✅ Incident Report Writer prompt
- ✅ Documentation and usage guidelines
These prompts and templates are provided as-is for use in security compliance activities. Modify and adapt as needed for your organization's specific requirements.
Last Updated: October 21, 2025
Maintained by: Security & Compliance Team
Repository: /Users/jm/rr/prompts-sec-comp