Prompts für das Design und die Implementierung von SOC 2-Kontrollen

Create a comprehensive SOC 2 control matrix for [organization name] covering [list applicable criteria: Security, Availability, etc.]. For each Trust Services Criterion in scope, provide:
- Criterion reference (e.g., CC6.1)
- Control objective
- Our control activity description
- Control type (preventive/detective/corrective)
- Control frequency (continuous/daily/monthly/quarterly/annual)
- Control owner (role)
- Evidence of operation

Our environment: [describe systems, organization size, tech stack]
Audit type: [Type I or Type II]

Help me prioritize SOC 2 control implementation based on risk. Analyze:
- Our risk assessment results: [summarize key risks]
- Criteria in scope: [Security, Availability, etc.]
- Current control maturity: [describe current state]
- Time to audit: [months until readiness assessment]
- Resource constraints: [team size, budget]

Provide a prioritized control implementation roadmap with quick wins and critical controls.

Design controls for CC1 (Control Environment) addressing:
- CC1.1 (integrity and ethical values): Code of conduct, ethics training
- CC1.2 (board oversight): [describe your governance structure]
- CC1.3 (organizational structure): Roles and responsibilities for security
- CC1.4 (competence): Training and qualification requirements
- CC1.5 (accountability): Performance management and enforcement

Our organization:
- Size: [employee count]
- Governance: [board structure, committees]
- Leadership: [who owns security/compliance]

Create controls for CC2 (Communication and Information) covering:
- CC2.1 (security objectives): How we communicate security goals
- CC2.2 (internal communication): [tools and channels for security communications]
- CC2.3 (external communication): Customer/vendor security communications

Include specific control activities, frequency, and responsible parties for our environment: [describe communication channels and stakeholders]

Design a risk assessment control framework for CC3.1 through CC3.4:
- CC3.1 (objectives): Service commitment and system requirements
- CC3.2 (risk identification): Methodology for identifying threats
- CC3.3 (risk analysis): Likelihood and impact assessment
- CC3.4 (fraud risk): Fraud risk scenarios specific to [your service type]

Our risk profile:
- Service type: [SaaS/PaaS/other]
- Threat landscape: [industry-specific threats]
- Previous incidents: [if any]

Provide control descriptions, frequency (how often risk assessments occur), and deliverables.

Generate monitoring controls for CC4.1 and CC4.2:
- CC4.1 (ongoing monitoring): Continuous monitoring of [list key systems/controls]
- CC4.2 (remediation): Process for addressing deficiencies

Include:
- Monitoring tools: [SIEM, log management, vulnerability scanners]
- Metrics and dashboards
- Review frequency and responsibilities
- Escalation and remediation workflows

Current monitoring capabilities: [describe existing tools and practices]

Design control activities for CC5.1 through CC5.3:
- CC5.1 (selection and development): Technology controls selection
- CC5.2 (general controls): IT general controls (access, change, backups)
- CC5.3 (deployment): Control deployment and configuration

Technology environment:
- Infrastructure: [cloud/on-prem/hybrid]
- Key technologies: [AWS/Azure/GCP, databases, applications]
- Automation level: [manual/semi-automated/fully automated]

For each control, specify the technology involved, how it operates, and who maintains it.

Create detailed access control controls for CC6.1 through CC6.8:
- CC6.1 (access management): Provisioning/deprovisioning process
- CC6.2 (authentication): [MFA requirements, password standards]
- CC6.3 (provisioning/deprovisioning): Joiner/mover/leaver workflow
- CC6.6 (physical access): [data center/office security if applicable]
- CC6.7 (access reviews): Quarterly access reviews
- CC6.8 (credentials): Privileged access management

Our access landscape:
- User count: [total users, admin users]
- Systems: [SSO, directory services, privileged access tools]
- Physical locations: [office locations, data centers]

Include who performs access reviews, what evidence is retained, and how exceptions are handled.

Design system operations controls for CC7.1 through CC7.5:
- CC7.1 (change detection): File integrity monitoring, configuration drift detection
- CC7.2 (security incidents): Incident detection and alerting
- CC7.3 (incident response): Response playbooks and procedures
- CC7.4 (incident mitigation): Containment and remediation
- CC7.5 (logging): [log sources, retention: X months/years]

Our operations:
- Monitoring tools: [SIEM, IDS/IPS, EDR]
- Incident history: [types of incidents experienced]
- Log infrastructure: [centralized logging, SIEM]

Specify how each control operates, evidence generated, and responsible teams.

Create change management controls for CC8.1:
- Change request and approval workflow
- Change categories: [standard/normal/emergency]
- Testing requirements: [dev/staging/production pipeline]
- Deployment controls: [CI/CD gates, approvals]
- Backout procedures
- Post-implementation validation

Our development environment:
- Methodology: [Agile/Waterfall/DevOps]
- Release frequency: [continuous/weekly/monthly]
- Tools: [Jira, ServiceNow, GitHub, Jenkins, etc.]

Detail the control at each stage (request → approval → testing → deployment → validation) and who is responsible.

Design risk mitigation controls for CC9.1 and CC9.2:
- CC9.1 (backups, disaster recovery): Backup and DR procedures
- CC9.2 (vendor management): Third-party risk management

Backup and DR:
- Backup frequency: [daily incremental, weekly full]
- Retention: [30 days online, 1 year archive]
- DR testing: [annual/semi-annual]
- RTO/RPO: [targets]

Vendor management:
- Critical vendors: [list key subservice organizations]
- Due diligence: [SOC 2 report review, security assessments]
- Contract requirements: [audit rights, SLAs]
- Monitoring: [annual reviews]

Provide detailed control descriptions with specific activities, frequency, and evidence.

Generate controls specific to SOC 2 Availability criteria (A1.1, A1.2, A1.3):
- A1.1 (availability objectives): Uptime targets and measurement
- A1.2 (capacity): Capacity monitoring, planning, and scaling
- A1.3 (monitoring and incident response): Availability incident management

Our availability commitments:
- SLA: [99.9% uptime or specific commitment]
- Systems: [production services in scope]
- Infrastructure: [cloud provider, redundancy approach]
- Historical performance: [past availability metrics]

For each control, specify monitoring tools, thresholds, escalation, and how we demonstrate compliance.

Create controls for SOC 2 Processing Integrity criteria (PI1.1 through PI1.5):
- PI1.1 (processing objectives): Accuracy and completeness targets
- PI1.2 (inputs): Input validation and authorization
- PI1.3 (processing): Processing logic controls and error handling
- PI1.4 (outputs): Output validation and reconciliation
- PI1.5 (data stores): Data integrity controls

Our processing environment:
- Processing activities: [payment processing, data transformation, calculations]
- Input sources: [APIs, file uploads, manual entry]
- Validation requirements: [regulatory or business rules]
- Reconciliation frequency: [real-time/daily/monthly]

Describe automated and manual controls, validation rules, and exception handling.

Design controls for SOC 2 Confidentiality criteria (C1.1, C1.2):
- C1.1 (confidential information): Identification and classification
- C1.2 (disposal): Secure deletion and destruction

Confidential data we handle:
- Data types: [customer proprietary data, trade secrets, financial data]
- Storage locations: [databases, file systems, backups]
- Encryption: [at rest, in transit standards]
- Retention periods: [by data type]

Include data classification scheme, encryption controls, access restrictions, and secure disposal procedures with evidence of execution.

Generate controls for SOC 2 Privacy criteria (P1.0 through P8.0):
- P1.0 (notice): Privacy notice provision and updates
- P2.0 (choice and consent): Consent collection and management
- P3.0 (collection): Data minimization and purpose limitation
- P4.0 (use, retention, disposal): Retention schedule enforcement
- P5.0 (access): Data subject access request handling
- P6.0 (disclosure to third parties): Third-party data sharing controls
- P7.0 (security): Privacy-specific security controls
- P8.0 (quality): Data accuracy and correction

Our privacy landscape:
- Personal data: [categories collected]
- Data subjects: [customers, employees, end users]
- Regulations: [GDPR, CCPA, other]
- Privacy tools: [consent management, DSR platforms]

For each principle, provide specific controls, automation where possible, and evidence of operation.

Evaluate the design of my control for [Trust Services Criterion reference]:

Control description:
[Paste your control description]

Assess:
- Does this control adequately address the criterion's requirements and points of focus?
- Are there design gaps or weaknesses?
- Is the control frequency appropriate?
- Is the control owner role suitable?
- What evidence should this control generate?

Provide recommendations for strengthening the control design.

I need to demonstrate operating effectiveness for my SOC 2 Type II audit covering [date range]. For control [control ID/description]:
- Control frequency: [daily/monthly/quarterly]
- Control type: [automated/manual/hybrid]
- Evidence generated: [logs, tickets, approvals, reports]

Help me plan:
- Sample size auditors will expect (for manual controls)
- Evidence retention and organization
- Documentation of exceptions and how they were resolved
- Testing approach to validate effectiveness before the audit

Provide a testing plan and evidence checklist.

Review my control set for [criteria in scope] and identify automation opportunities:

Current controls:
[List your controls and whether they're manual/automated]

Available technologies:
[List tools and platforms you have: SIEM, IaC, policy-as-code, etc.]

Recommend:
- Which controls can be fully automated
- Tools or scripts to implement automation
- Continuous compliance approaches
- How automation improves audit evidence quality

Prioritize by impact and implementation effort.