SOC 2 policy and procedure prompts
Generating SOC 2-compliant policies
These prompts help you create policies and procedures that align with Trust Services Criteria requirements and provide the governance foundation auditors expect.
Upload your existing policies before generating new ones. ISMS Copilot can analyze gaps and suggest updates rather than creating from scratch.
Core governance policies
Information security policy
Create a comprehensive Information Security Policy for [organization name] that supports our SOC 2 [Security/+other criteria] scope. Include:
- Purpose and scope aligned to Trust Services Criteria
- Roles and responsibilities (CISO, security team, employees)
- Security governance structure
- Risk management approach
- Policy compliance and enforcement
- Review and update procedures
Target audience: [all employees, specific departments]
Organization size: [number of employees]
Industry: [your industry] Access control policy
Generate an Access Control Policy addressing SOC 2 Common Criteria CC6.1, CC6.2, and CC6.3. Cover:
- User access provisioning and deprovisioning (joiner/mover/leaver)
- Role-based access control (RBAC) principles
- Least privilege and segregation of duties
- Privileged access management
- Access review procedures (frequency: [quarterly/annual])
- Guest and third-party access
- Remote access requirements
Our environment: [describe systems, user count, access technologies] Change management policy
Draft a Change Management Policy that satisfies SOC 2 CC8.1. Include:
- Change request and approval workflow
- Change categories (standard, normal, emergency)
- Testing and validation requirements
- Rollback procedures
- Communication protocols
- Post-implementation review
Our change environment:
- Systems: [production systems in scope]
- Release frequency: [weekly/monthly/continuous]
- Team structure: [dev, ops, security teams] Operational procedures
Incident response procedure
Create an Incident Response Procedure aligned with SOC 2 CC7.3 and CC7.4 for [organization name]. Address:
- Incident classification and severity levels
- Detection and reporting mechanisms
- Response team roles (incident commander, communications, technical)
- Investigation and containment steps
- Evidence preservation
- Communication plan (internal, customers, regulators)
- Post-incident review and lessons learned
Incident types we face: [e.g., security breaches, availability incidents, data integrity issues]
Compliance requirements: [breach notification laws if applicable] Backup and recovery procedure
Develop a Backup and Recovery Procedure supporting SOC 2 CC9.1 and [Availability A1.2 if applicable]. Cover:
- Systems and data in scope for backup
- Backup frequency and retention: [daily/weekly, retention period]
- Backup types: [full, incremental, differential]
- Backup storage locations: [on-site, off-site, cloud]
- Recovery time objective (RTO): [target]
- Recovery point objective (RPO): [target]
- Testing procedures: [frequency and scope]
- Roles and responsibilities
Our infrastructure: [on-prem/cloud/hybrid, key systems] Vendor management procedure
Create a Vendor Management Procedure for SOC 2 CC9.2. Include:
- Vendor risk assessment criteria
- Due diligence requirements (SOC 2 reports, security questionnaires)
- Contract requirements (SLAs, data protection clauses, audit rights)
- Ongoing monitoring and review (frequency: [annual/quarterly])
- Vendor termination and data return
- Subservice organization considerations
We use vendors for: [list critical third-party services]
Data shared: [types of data sent to vendors] SOC 2 auditors pay close attention to vendor management. Ensure your procedure addresses how you monitor subservice organizations and obtain their SOC 2 reports.
Availability-specific procedures
Capacity management procedure
Generate a Capacity Management Procedure for SOC 2 Availability criterion A1.2. Cover:
- Capacity monitoring metrics: [CPU, memory, storage, network]
- Threshold and alert definitions
- Capacity forecasting methodology
- Capacity planning cycle: [quarterly/annual]
- Scaling procedures (vertical and horizontal)
- Performance testing requirements
Our infrastructure:
- Environment: [cloud provider or on-prem]
- Auto-scaling: [yes/no, which services]
- Growth rate: [expected user/data growth] Availability monitoring procedure
Create an Availability Monitoring and Incident Management Procedure addressing A1.1 and A1.3. Include:
- Availability metrics and targets: [uptime SLA]
- Monitoring tools and configuration: [tools you use]
- Alerting and escalation procedures
- Incident response for availability events
- Communication protocols (status pages, customer notifications)
- Post-incident analysis and SLA reporting
Services monitored: [list critical services]
Availability commitment: [e.g., 99.9% uptime] Privacy-specific policies
Data privacy policy
Draft a Data Privacy Policy aligned with SOC 2 Privacy criteria and [GDPR/CCPA/other regulations]. Address:
- Privacy principles (notice, choice, collection, use, retention, access, disclosure, security)
- Legal basis for processing: [consent, contract, legitimate interest]
- Data subject rights (access, correction, deletion, portability)
- International data transfers: [mechanisms if applicable]
- Privacy by design and default
- Data protection impact assessments (DPIAs)
- Privacy incident response
Personal data we process: [list categories]
Data subjects: [customers, employees, end users]
Geographic scope: [regions] Data retention and disposal procedure
Create a Data Retention and Disposal Procedure supporting Privacy and Confidentiality criteria. Cover:
- Retention schedules by data type:
[Data type 1]: [retention period and justification]
[Data type 2]: [retention period and justification]
- Legal and regulatory retention requirements
- Secure disposal methods (data erasure, physical destruction)
- Disposal verification and certification
- Roles and responsibilities
- Exception handling
Our data landscape: [databases, backups, archives, physical media] Processing Integrity procedures
Data validation and quality procedure
Generate a Data Validation and Quality Procedure for SOC 2 Processing Integrity criterion PI1.4. Include:
- Input validation rules and controls
- Data quality dimensions (accuracy, completeness, consistency, timeliness)
- Automated validation checks
- Manual review processes
- Error handling and correction workflows
- Quality metrics and reporting
Our processing activities: [describe data flows and transformations]
Quality requirements: [accuracy thresholds, validation rules] Processing monitoring procedure
Create a Processing Monitoring and Reconciliation Procedure addressing PI1.1 through PI1.5. Cover:
- Processing metrics and KPIs
- Automated monitoring and alerts
- Reconciliation procedures (frequency: [daily/weekly/monthly])
- Exception investigation and resolution
- Processing logs and audit trails
- Reporting and escalation
Systems in scope: [list processing systems]
Critical processes: [payment processing, data transformation, etc.] Policy maintenance and communication
Policy review and update procedure
Draft a Policy and Procedure Review and Update process that satisfies SOC 2 governance requirements. Include:
- Review frequency: [annual/biannual]
- Review triggers (regulatory changes, incidents, audit findings)
- Review responsibilities (policy owners, stakeholders, approvers)
- Version control and change tracking
- Communication and training on updates
- Archive and retention of superseded versions
Current policy inventory: [number of policies, last review dates] Security awareness training plan
Create a Security Awareness Training Plan supporting CC1.4 (security awareness and training). Cover:
- Training audience and role-based requirements
- Core training topics (phishing, passwords, data handling, incident reporting)
- Training delivery methods: [online modules, in-person, phishing simulations]
- Training frequency: [annual mandatory, ongoing awareness]
- New hire onboarding training
- Specialized training (developers, administrators, managers)
- Effectiveness measurement (quizzes, simulations, metrics)
- Record keeping
Organization size: [employee count]
Risk profile: [industry, threat landscape] Policies must be formally approved by management and communicated to relevant personnel. Document approvals and training completion as audit evidence.
Customization tips
Tailoring policies to your organization
I've generated a [policy name] using your prompts. Help me tailor it to our organization:
- Organization specifics: [size, industry, structure]
- Existing practices: [what we already do]
- Technology stack: [tools and platforms we use]
- Regulatory environment: [applicable laws and regulations]
- Risk appetite: [conservative/moderate/aggressive]
Review the draft policy and suggest specific customizations that reflect our actual practices and environment. Combine policy generation with gap analysis prompts to ensure your policies address all applicable Trust Services Criteria and reflect your actual practices.