SOC 2 documentation and reporting prompts

Document our system architecture for SOC 2 purposes:

System overview:
- Service name: [your service]
- Deployment model: [cloud/on-prem/hybrid]
- Architecture pattern: [microservices/monolith/serverless]

Infrastructure components:
- Cloud provider(s): [AWS/Azure/GCP]
- Compute: [EC2/VMs/containers/serverless]
- Storage: [databases, object storage, file systems]
- Network: [VPCs, load balancers, CDN]
- Security: [firewalls, WAF, DDoS protection]

Create:
- Written architecture description suitable for the system description
- Component inventory with security relevance
- Data flow descriptions (how data enters, is processed, stored, and exits)
- Network diagrams or descriptions
- Integration points and external dependencies

Make it auditor-friendly and aligned to Trust Services Criteria.

Document data flows for our SOC 2 system description:

Data types processed:
- [Data type 1, e.g., customer PII]: [how collected, processed, stored, deleted]
- [Data type 2, e.g., payment information]: [lifecycle]
- [Data type 3]: [lifecycle]

For each data flow, describe:
- Data source (user input, API, third party)
- Collection method and validation
- Processing and transformations
- Storage location and encryption
- Access controls
- Retention and disposal
- Third-party sharing (if any)

Create data flow diagrams or narratives that demonstrate compliance with Privacy, Confidentiality, and Processing Integrity criteria if in scope.

Create a Statement of Applicability for our SOC 2 audit covering [criteria in scope]:

For each Trust Services Criterion:
- Criterion reference and title
- Applicability status (Applicable/Not Applicable/Partially Applicable)
- Justification for applicability status
- If applicable: summary of how we address it (control summary)
- If not applicable: rationale for exclusion

Organization context:
- Service type: [your service]
- Scope boundaries: [what's in/out of scope]
- Service commitments: [uptime, security guarantees, etc.]

Format as a table with columns: Criterion | Applicability | Justification | Control Summary

Generate a gap analysis report comparing our current state to SOC 2 requirements:

Assessment scope:
- Target criteria: [Security, Availability, etc.]
- Audit type: [Type I or Type II]
- Assessment date: [when performed]

Current state:
- Existing controls: [describe what you have]
- Policies and procedures: [what's documented]
- Technical safeguards: [tools and technologies]
- Known weaknesses: [gaps you're aware of]

For each Trust Services Criterion in scope, provide:
- Requirement summary
- Current compliance level (Compliant/Partially Compliant/Non-Compliant)
- Gap description (what's missing or insufficient)
- Risk rating (Critical/High/Medium/Low)
- Remediation recommendation
- Estimated effort and timeline

Summarize in an executive summary suitable for leadership review.

Create a SOC 2 compliance roadmap from current state to audit readiness:

Starting point:
- Current maturity: [describe current control environment]
- Known gaps: [list major gaps]
- Resources available: [team size, budget, tools]

Target:
- Audit type and criteria: [Type I/II, Security + others]
- Target audit date: [date]
- Time available: [months to prepare]

Provide a phased roadmap with:
- Phase 1 (Months 1-2): Foundational work (policies, governance, critical controls)
- Phase 2 (Months 3-4): Control implementation and documentation
- Phase 3 (Months 5-6): Evidence collection and internal testing
- Phase 4 (Months 7+): Readiness assessment and audit (Type II needs longer for evidence)

For each phase, list key deliverables, milestones, and dependencies.

Design a SOC 2 compliance dashboard for reporting to leadership:

Metrics to track:
- Control implementation status (% complete)
- Gap remediation progress
- Evidence collection status
- Policy and procedure completion
- Training completion rates
- Incidents and exceptions
- Readiness score by Trust Services Criterion
- Timeline to audit readiness

For each metric, provide:
- Calculation method
- Target/acceptable threshold
- Current status
- Trend (improving/stable/declining)
- RAG status (Red/Amber/Green)

Create a narrative summary of overall SOC 2 program health suitable for quarterly board or executive reporting.

Define metrics to measure and report SOC 2 control effectiveness:

For key control categories:
- Access management: [e.g., access review completion rate, access requests processed on time]
- Change management: [e.g., change success rate, unauthorized changes detected]
- Incident response: [e.g., incident detection time, mean time to resolution]
- Monitoring: [e.g., alert investigation rate, false positive percentage]
- Backup and recovery: [e.g., backup success rate, recovery test pass rate]

For each metric, provide:
- Metric definition and calculation
- Data source
- Target value
- Reporting frequency
- Responsible party for monitoring

Create a control effectiveness scorecard suitable for monthly or quarterly review.

Create a comprehensive policy register for our SOC 2 program:

For each policy relevant to Trust Services Criteria, document:
- Policy name and document ID
- Related Trust Services Criteria
- Policy owner (role)
- Approval date and approver
- Last review date
- Next review date (annual/biannual)
- Version number
- Distribution (who must acknowledge)
- Acknowledgment status

Policies to include:
[List policies you have or need: Information Security, Access Control, Change Management, Incident Response, etc.]

Format as a table and identify any missing policies or overdue reviews.

Create a detailed procedure document for [specific procedure name, e.g., "User Access Provisioning"]:

Procedure elements to include:
- Purpose and scope
- Related policies and Trust Services Criteria
- Roles and responsibilities
- Prerequisites
- Step-by-step instructions with decision points
- Tools and systems involved
- Timing and frequency
- Documentation and evidence requirements
- Exception handling
- Escalation procedures
- Related procedures (cross-references)

Our environment:
[Describe relevant systems, tools, and roles for this procedure]

Ensure the procedure is detailed enough for a new team member to follow and for auditors to test.

Create an evidence catalog for our SOC 2 [Type I/Type II] audit:

For each control in our control matrix:
- Control ID and description
- Trust Services Criterion addressed
- Evidence type (log, screenshot, report, ticket, approval, meeting minutes)
- Evidence location (system, folder, tool)
- Collection method (automated export, manual screenshot, etc.)
- Collection frequency (point-in-time for Type I, period for Type II)
- Responsible person
- Evidence status (Collected/Pending/Not Available)

Create a checklist auditors can use to request and review evidence efficiently.

Generate an evidence summary report for [specific control or Trust Services Criterion]:

Control/Criterion: [name]
Audit period: [date range]
Evidence provided:

For each piece of evidence:
- Evidence identifier (e.g., filename, log entry ID)
- Evidence type (log, report, screenshot, etc.)
- Date generated or applicable date
- What it demonstrates (specific control activity)
- Where auditors can find it
- Any annotations or context needed

Provide a narrative summary explaining how the collection of evidence demonstrates the control operated effectively throughout the audit period (Type II).

Draft a management assertion letter for our SOC 2 [Type I/Type II] audit:

Organization details:
- Entity name: [legal name]
- Service description: [brief description]
- Audit period: [date or date range]
- Criteria in scope: [Security, Availability, etc.]

The assertion letter should assert that:
- Management is responsible for the system and controls
- The system description fairly presents the system
- Controls are suitably designed (Type I) and operating effectively (Type II)
- The Trust Services Criteria are met

Include:
- Description of our service and boundaries
- Management's responsibilities
- Criteria for evaluating controls
- Inherent limitations of any system of controls

Format as a formal letter for CEO/CFO signature.

Create a comprehensive "Provided By Client" (PBC) request list for our SOC 2 audit to proactively prepare documentation:

For each Trust Services Criterion in scope, list:
- Documents auditors will request (policies, procedures, architecture docs)
- Evidence samples (logs, tickets, approvals, screenshots)
- Interviews they'll want to conduct
- System access they'll need
- Walkthroughs they'll perform

Organize by:
- Documents (all policies, procedures, diagrams)
- Evidence by control
- People (interview participants and their roles)
- System access (read-only accounts, scoping)

Include target provision date and responsible person for each item. This becomes your master audit preparation checklist.

Create a remediation plan for audit findings or observations:

Findings received:
[List findings from audit report or management letter]

For each finding, provide:
- Finding summary
- Root cause analysis
- Remediation action plan (specific steps)
- Responsible party
- Target completion date
- Validation method (how we'll prove it's fixed)
- Status updates

Include an executive summary for leadership and a detailed project plan for implementation teams.

Develop a continuous improvement plan for our SOC 2 program post-audit:

Current state:
- Audit outcome: [Type I/II, criteria, clean/with findings]
- Lessons learned: [what went well, what was challenging]
- Auditor feedback: [recommendations beyond formal findings]

Improvement areas:
- Control enhancements (automation, efficiency)
- Documentation improvements
- Evidence collection streamlining
- Metrics and monitoring expansion
- Preparation for expanded scope (additional criteria)
- Transition from Type I to Type II (if applicable)

Create a 12-month improvement roadmap with quarterly objectives and KPIs to measure progress.

Create customer-facing security documentation based on our SOC 2 compliance:

Target audience: [enterprise customers, security teams, procurement]

Content to include:
- Overview of our SOC 2 compliance (Type, criteria, report availability)
- Trust Services Criteria we meet
- How to request our SOC 2 report (NDA requirements)
- Security and privacy commitments
- Complementary User Entity Controls (what customers must do)
- Certifications and attestations beyond SOC 2
- Security contact information
- Incident notification procedures

Tone: Reassuring but not overly technical. Focus on how our SOC 2 compliance protects customer data and supports their compliance needs.

Develop a SOC 2 FAQ to help our sales and marketing teams address customer questions:

Common questions to address:
- What is SOC 2 and why does it matter?
- What type of SOC 2 report do we have? (Type I/II, criteria)
- How often is our audit conducted and by whom?
- How can customers access our SOC 2 report?
- What's the difference between SOC 2 Type I and Type II?
- Do we have other certifications? (ISO 27001, PCI DSS, etc.)
- How does SOC 2 help customers meet their compliance requirements?
- What are Complementary User Entity Controls and what must customers do?
- How do we handle security incidents?
- What's our uptime/availability commitment?

For each question, provide a concise, customer-friendly answer that sales can use in conversations and RFP responses.