Security Overview

Document owner: Chief Information Security Officer (CISO) Version: 3.0 Effective date: January 1, 2026 Last updated: January 15, 2026 Classification: Public — Trust Center Review cadence: Quarterly, and upon material architecture, vendor, or threat landscape changes Company: Acme Cloud, Inc. Address: 1200 Market Street, Suite 400, San Francisco, CA 94103, USA Primary contacts: trust@acmecloud.com | security@acmecloud.com | privacy@acmecloud.com

---

Definitions

Term	Definition
AWS	Amazon Web Services, the primary infrastructure provider for Acme Cloud production systems
CMK	Customer Master Key, the top-level encryption key in AWS KMS hierarchy
CUEC	Complementary User Entity Controls, customer responsibilities in a shared responsibility model
DEK	Data Encryption Key, symmetric key used to encrypt data directly
EDR	Endpoint Detection and Response, security software for threat detection on endpoints
FIDO2	Fast Identity Online 2, passwordless authentication standard using public-key cryptography
HSTS	HTTP Strict Transport Security, mechanism forcing HTTPS connections
IaC	Infrastructure as Code, managing infrastructure through machine-readable definition files
ISMS	Information Security Management System, framework for managing security policies and controls
JIT	Just-in-Time, access provisioning approach granting privileges only when needed
KMS	Key Management Service, AWS service for creating and managing encryption keys
MFA	Multi-Factor Authentication, requiring multiple verification methods for access
mTLS	Mutual TLS, bidirectional certificate authentication for service-to-service communication
NIST CSF	National Institute of Standards and Technology Cybersecurity Framework
PAM	Privileged Access Management, controlling elevated system access
RTO	Recovery Time Objective, target duration for restoring service after disruption
RPO	Recovery Point Objective, maximum acceptable data loss measured in time
SIEM	Security Information and Event Management, centralized security monitoring platform
SOC 2	Service Organization Control 2, trust services audit framework
TSC	Trust Services Criteria, principles for SOC 2 compliance
VPC	Virtual Private Cloud, isolated network environment within AWS
WAF	Web Application Firewall, filtering malicious web traffic
WebAuthn	Web Authentication API, browser standard for FIDO2 authentication
ZTA	Zero Trust Architecture, security model requiring verification for all access requests

---

Scope and Applicability

1.1 Organizational Scope

This Security Overview applies to the entire Acme Cloud, Inc. organization, including all subsidiaries, divisions, and affiliated entities. The scope encompasses all personnel with access to Acme Cloud systems, data, or facilities, including full-time employees, part-time employees, contractors, consultants, temporary workers, interns, and third-party service providers operating on behalf of Acme Cloud.

1.2 Technical Scope

The security program covers all technology systems and infrastructure operated by or on behalf of Acme Cloud:

System Category	Scope Inclusion	Examples
Production Infrastructure	Full scope	AWS accounts hosting customer-facing SaaS platform
Staging Environments	Full scope when containing customer data copies	Pre-production validation environments
Development Environments	Partial scope (code security, access controls)	Developer workstations, CI/CD pipelines
Corporate IT Systems	Full scope for systems accessing production	Okta, Google Workspace, Slack, Jira
Third-Party Integrations	Risk-based scope per vendor tier	Payment processors, analytics providers
Physical Facilities	Physical security controls only	Office locations, data center colocations

1.3 Data Scope

All data processed, stored, or transmitted by Acme Cloud systems falls within scope of this security program. Data classification determines specific control requirements:

Classification	Scope Treatment	Encryption Requirement	Access Restriction
Public	Integrity controls only	Optional	None
Internal	Standard security controls	Recommended	Role-based
Confidential	Enhanced controls, monitoring	Required	Need-to-know
Restricted	Maximum controls, audit	Required with field-level	Explicit approval

1.4 Exclusions

The following are explicitly excluded from scope: personal devices not enrolled in mobile device management (MDM), customer-owned systems accessing Acme Cloud via public APIs (covered by shared responsibility), and third-party services where Acme Cloud is solely a consumer without administrative access.

---

Security Governance Framework

2.1 Governance Structure

Acme Cloud maintains a multi-tiered security governance structure with clear accountability, escalation paths, and decision-making authority.

Governance Body	Members	Meeting Cadence	Responsibilities
Board Audit Committee	Independent directors (3)	Quarterly	Security risk oversight, compliance attestation approval
Executive Security Committee	CEO, CTO, CISO, CFO, CLO	Monthly	Security strategy, major incident review, budget approval
Security Leadership Team	CISO, Security Directors (4)	Weekly	Operational decisions, policy approval, program management
Security Architecture Review Board	CISO, Principal Architects (3), Security Engineering Lead	Bi-weekly	Technical standards, design reviews, exception approvals
Incident Response Team	CISO, Security Ops Lead, Engineering On-Call, Legal, Communications	As needed	Active incident management, customer notification decisions

2.2 Roles and Responsibilities (RACI Matrix)

Activity	Board	CEO	CISO	Security Engineering	Engineering Teams	HR	Legal
Security strategy approval	A	R	C	I	I	I	C
Policy development	I	I	A	R	C	C	C
Control implementation	I	I	A	R	R	I	I
Risk assessment	I	C	A	R	C	I	C
Incident response	I	I	A	R	C	C	R
Compliance attestation	A	R	R	C	I	I	C
Security awareness training	I	I	A	C	I	R	I
Vendor security review	I	I	A	R	I	I	C
Background checks	I	I	C	I	I	A/R	C
Breach notification	A	C	R	C	I	I	R

Legend: R = Responsible, A = Accountable, C = Consulted, I = Informed

2.3 Security Organization Structure

The Security organization comprises 32 full-time employees organized into specialized teams:

Team	Headcount	Leader	Primary Functions
Security Engineering	14	Director, Security Engineering	Infrastructure security, security tooling, detection engineering
Governance, Risk & Compliance	5	Director, GRC	Policy management, audit coordination, compliance monitoring
Security Operations	7	Director, Security Operations	24/7 monitoring, incident response, threat intelligence
Privacy Engineering	3	Privacy Engineering Manager	Privacy controls, data protection, DSR automation
Application Security	3	Application Security Lead	Secure SDLC, code review, penetration testing coordination

The CISO reports directly to the CEO with a dotted-line reporting relationship to the Board Audit Committee. Security budget represents 9.1% of total engineering spend for FY2026.

2.4 Policy Framework

Acme Cloud maintains a hierarchical policy framework:

Policy Level	Approval Authority	Review Cadence	Examples
Enterprise Policies	Executive Security Committee	Annual	Information Security Policy, Acceptable Use Policy
Standards	CISO	Annual	Encryption Standards, Access Control Standards
Procedures	Security Leadership Team	Semi-annual	Incident Response Procedures, Change Management Procedures
Guidelines	Security Engineering	As needed	Secure Coding Guidelines, Cloud Configuration Guidelines
Runbooks	Security Operations	Quarterly	Incident runbooks, operational playbooks

All policies are version-controlled in a central repository with approval workflows. Policy changes require formal change request, impact assessment, stakeholder review, and documented approval before publication.

---

Information Security Management System (ISMS)

3.1 ISMS Scope and Objectives

Acme Cloud operates an ISMS aligned with ISO/IEC 27001:2022 requirements. The ISMS scope encompasses the design, development, operation, and support of the Acme Cloud SaaS platform, including all supporting infrastructure, personnel, and processes.

ISMS objectives for FY2026:

Objective	Metric	Target	Current Status
Achieve ISO 27001 certification	Certification status	Certified by Q3 2026	Stage 1 audit completed
Maintain zero material security breaches	SEV1 incidents with data exfiltration	0	0 (on track)
Reduce critical vulnerability MTTR	Hours to remediate critical findings	< 48 hours	52 hours average
Achieve security training completion	Percentage of workforce trained	100%	98.7%
Complete all access reviews on schedule	Reviews completed on time	100%	100%

3.2 Risk Management Process

Acme Cloud conducts formal risk assessments following a defined methodology:

Step 1: Asset Identification 1.1. Inventory all information assets within ISMS scope 1.2. Assign asset owners and custodians 1.3. Classify assets per data classification policy 1.4. Document asset dependencies and interconnections

Step 2: Threat and Vulnerability Assessment 2.1. Identify applicable threats using MITRE ATT&CK framework 2.2. Assess vulnerabilities through automated scanning and manual review 2.3. Evaluate threat actor capabilities and likelihood 2.4. Document threat scenarios with potential impact

Step 3: Risk Calculation and Prioritization 3.1. Calculate inherent risk using likelihood × impact matrix 3.2. Evaluate existing control effectiveness 3.3. Calculate residual risk post-controls 3.4. Prioritize risks by residual risk score

Likelihood	Impact: Negligible	Impact: Minor	Impact: Moderate	Impact: Major	Impact: Severe
Almost Certain	Medium	High	High	Critical	Critical
Likely	Low	Medium	High	High	Critical
Possible	Low	Medium	Medium	High	High
Unlikely	Low	Low	Medium	Medium	High
Rare	Low	Low	Low	Medium	Medium

Step 4: Risk Treatment 4.1. Select treatment option: mitigate, transfer, accept, or avoid 4.2. Design and implement controls for mitigation 4.3. Document risk acceptance for residual risk above threshold (requires CISO approval for High, Executive Committee for Critical) 4.4. Monitor control effectiveness and residual risk continuously

3.3 Continuous Improvement

The ISMS improvement cycle includes:

Input Source	Frequency	Review Process	Improvement Output
Internal audits	Quarterly	GRC review, finding tracking	Control enhancements, procedure updates
External audits	Annual	Management review, action planning	Policy revisions, training updates
Incident post-mortems	Per incident	Lessons learned meetings	Runbook updates, detection improvements
Threat intelligence	Continuous	Security Operations analysis	Control adjustments, monitoring rules
Customer feedback	Continuous	Trust team aggregation	Feature requests, documentation updates
Regulatory changes	As needed	Legal and GRC assessment	Policy updates, control additions

---

Infrastructure Security Architecture

4.1 Cloud Infrastructure Overview

Acme Cloud production infrastructure operates exclusively on Amazon Web Services (AWS) with a multi-region architecture:

Environment	Primary Region	DR Region	Purpose	Network Isolation
Production	us-east-1 (N. Virginia)	eu-west-1 (Ireland)	Customer-facing SaaS platform	Dedicated VPC, private subnets
Staging	us-east-1	N/A	Pre-production validation with sanitized data	Separate VPC, no production connectivity
Development	us-east-1	N/A	Developer environments, CI/CD	Isolated VPC, no customer data
Corporate	us-east-1	N/A	Internal tooling, security systems	Separate AWS account, VPC peering to production for monitoring only
DR-Hot	eu-west-1	N/A	Active-passive failover, real-time replication	Mirrored VPC architecture

4.2 Network Security Architecture

The production network implements a defense-in-depth architecture with multiple security layers:

Edge Security Layer

• Cloudflare CDN/WAF: DDoS protection, rate limiting, bot management, geographic restrictions
• AWS Shield Advanced: Network and application layer DDoS protection
• Custom WAF rules: OWASP Top 10 protection, application-specific signatures

Application Layer

• AWS Application Load Balancer: TLS termination, request routing, health checks
• AWS WAF integration: Additional filtering rules, IP reputation blocking
• Auto-scaling ECS services: Container-based microservices in private subnets
• Service mesh (AWS App Mesh): mTLS for service-to-service communication

Data Layer

• Amazon RDS PostgreSQL Multi-AZ: Primary database with automated failover
• Amazon ElastiCache Redis: Session storage and caching with encryption
• Amazon OpenSearch: Log aggregation and search with encryption at rest
• No direct internet connectivity: All data-tier resources in isolated private subnets

4.3 Network Segmentation and Access Controls

Subnet Tier	Internet Access	Cross-Tier Access	Security Group Rules
Public (Edge)	Inbound HTTPS only (443)	To Application tier only	Allowlist: ALB ports, WAF
Application	Outbound via NAT Gateway	From Public, to Data	Allowlist: Service ports, health checks
Data	None	From Application tier only	Allowlist: Database ports from app security groups
Management	Outbound via NAT Gateway	To all tiers (restricted)	Allowlist: SSH/RDP from bastion only

Network security controls:

Control	Implementation	Monitoring
VPC Flow Logs	All subnets, 14-day retention in S3, shipped to SIEM	Anomaly detection rules
AWS GuardDuty	Enabled for all accounts, findings to Security Hub	Automated alerting
Network ACLs	Stateless filtering at subnet boundaries	Quarterly review
Security Groups	Stateful filtering at instance/container level	IaC enforcement, drift detection
Transit Gateway	Controlled inter-VPC routing	Route table auditing

4.4 Infrastructure as Code and Configuration Management

All infrastructure is defined and managed through Infrastructure as Code:

Component	IaC Tool	Repository	Review Process
AWS Resources	Terraform	monorepo/infrastructure	PR review, automated security scanning
Kubernetes Manifests	Helm + Kustomize	monorepo/k8s	PR review, policy validation
Container Images	Dockerfile + CI	monorepo/services	Automated scanning, base image governance
Network Policies	Terraform + Calico	monorepo/infrastructure	Security Architecture Review Board
Secrets Management	Terraform + AWS Secrets Manager	monorepo/infrastructure	PR review, secret rotation automation

Configuration drift detection runs hourly. Unauthorized changes trigger immediate alerts and automatic remediation where safe.

---

Identity and Access Management

5.1 Workforce Identity Management

Acme Cloud uses Okta as the centralized identity provider for all workforce access:

Identity Component	Implementation	Security Controls
Directory	Okta Universal Directory	HR system integration, automated provisioning
SSO	Okta SSO	SAML 2.0 for all corporate applications
MFA	Okta Verify + FIDO2 keys	Required for all users, phishing-resistant preferred
Password Policy	Okta Password Policy	14+ characters, complexity requirements, breach database checks
Session Management	Okta Session Policy	12-hour maximum session, re-authentication for sensitive actions

5.2 Multi-Factor Authentication Requirements

Access Type	MFA Requirement	Approved Methods	Exceptions
Corporate SSO	Required	FIDO2 (preferred), Okta Verify Push, TOTP	None
Production Access	Required + Step-up	FIDO2 required	Break-glass only (documented)
VPN Access	Required	FIDO2, Okta Verify Push	None
Customer SSO (Enterprise)	Customer-configurable	SAML 2.0 assertion with MFA claim	Per customer security policy
API Access	Token-based	API keys with IP restrictions, OAuth 2.0	Service accounts (audited)

5.3 Privileged Access Management

Production access follows Just-in-Time (JIT) principles:

Standard Access Request Workflow

1. Engineer submits access request via internal PAM tool specifying resource, duration, and justification
2. System validates requestor role and entitlements
3. Request routes to appropriate approver (team lead for standard, Security for privileged)
4. Approver reviews justification and approves/denies within SLA
5. Upon approval, temporary credentials provisioned with specified duration
6. All session activity recorded for audit
7. Access automatically revoked at expiration

Access Level	Maximum Duration	Approval Required	Session Recording
Read-only production	8 hours	Team lead	Audit log only
Read-write production	4 hours	Security Operations	Full session recording
Database direct access	2 hours	CISO or delegate	Full session recording
Infrastructure admin	2 hours	Security Operations	Full session recording
Break-glass emergency	As needed	Post-incident review required	Full session recording

5.4 Access Reviews and Recertification

Review Type	Scope	Frequency	Reviewer	SLA for Completion
Production access	All users with production access	Monthly	Security Operations + Manager	5 business days
Privileged roles	Admin, security, infrastructure roles	Monthly	CISO or delegate	3 business days
Application access	All enterprise applications	Quarterly	Application owners	10 business days
Service accounts	All service accounts and API keys	Quarterly	Service owners	10 business days
Third-party access	Contractor and vendor accounts	Monthly	Sponsor + Security	5 business days
Dormant accounts	Accounts inactive > 30 days	Monthly	Automated + Security review	Immediate disable, 5-day review

5.5 Offboarding and Access Termination

Termination Type	Access Revocation SLA	Verification	Documentation
Voluntary departure	4 hours from notification	Security Operations checklist	HR system record
Involuntary termination	Immediate (before notification)	Security Operations checklist	HR system record
Contractor end of engagement	4 hours from sponsor notification	Security Operations checklist	Procurement system record
Role change (internal transfer)	24 hours for old role access	Manager + Security review	HR system record

Offboarding checklist includes: Okta account disable, production access revocation, email access removal, MFA device deregistration, laptop retrieval scheduling, exit interview scheduling, and knowledge transfer documentation.

---

Data Protection and Encryption

6.1 Data Classification Framework

Classification	Definition	Examples	Handling Requirements
Public	Information approved for public release	Marketing materials, public documentation	No restrictions
Internal	Business information for internal use	Internal wikis, non-sensitive communications	Access controls, no public sharing
Confidential	Sensitive business or customer information	Customer data, PII, financial records	Encryption required, need-to-know access
Restricted	Highly sensitive regulatory or contractual data	PHI, payment card data, encryption keys	Maximum controls, explicit authorization

6.2 Encryption Standards Summary

Data State	Standard	Implementation	Key Management
At Rest - Databases	AES-256	RDS encryption, transparent data encryption	AWS KMS with annual rotation
At Rest - Object Storage	AES-256	S3 SSE-KMS	Per-bucket CMKs
At Rest - Block Storage	AES-256	EBS encryption	AWS managed keys
At Rest - Backups	AES-256	Separate encryption keys	Dedicated backup CMKs
In Transit - External	TLS 1.2+ (1.3 preferred)	ALB termination, certificate automation	ACM managed
In Transit - Internal	mTLS	Service mesh with internal PKI	Automated certificate rotation
Application Layer	AES-256-GCM	Field-level encryption for sensitive fields	Tenant-specific DEKs wrapped by CMKs

Full encryption standards documented in /encryption-standards.

6.3 Data Loss Prevention Controls

DLP Control	Scope	Detection Method	Response Action
Email DLP	Outbound email	Pattern matching for PII, customer data	Block, quarantine, alert
Endpoint DLP	Workstations	USB transfer monitoring, screen capture detection	Block, alert, log
Cloud DLP	SaaS applications	API integration, content inspection	Alert, access review
Code Repository	GitHub	Secret scanning, sensitive data patterns	Block commit, alert
Data Transfer	AWS S3, database exports	Cross-account transfer monitoring	Alert, require approval

6.4 Data Residency and Sovereignty

Acme Cloud offers data residency options for enterprise customers:

Region Option	Primary Data Center	Backup Location	Applicable Regulations
United States	us-east-1 (N. Virginia)	us-west-2 (Oregon)	US domestic
European Union	eu-west-1 (Ireland)	eu-central-1 (Frankfurt)	GDPR, Schrems II
United Kingdom	eu-west-2 (London)	eu-west-1 (Ireland)	UK GDPR, Data Protection Act 2018
Asia Pacific	ap-southeast-1 (Singapore)	ap-northeast-1 (Tokyo)	Regional requirements

Data residency selection locks all customer data storage to the selected region. Metadata for global service functionality may traverse regions per documented data flow diagrams available upon request.

---

Vulnerability Management Program

7.1 Vulnerability Identification

Scanning Type	Scope	Frequency	Tools
Dependency scanning	Application dependencies	Every commit (CI/CD)	Snyk, Dependabot
Container scanning	Container images	Every build	Trivy, AWS ECR scanning
Infrastructure scanning	Cloud configuration	Continuous	AWS Config, Prisma Cloud
Web application scanning	Customer-facing applications	Weekly	OWASP ZAP, Burp Suite
Network scanning	Internal and external networks	Weekly	Nessus, Qualys
Code analysis (SAST)	Source code	Every commit	SonarQube, Semgrep

7.2 Vulnerability Severity and SLA

Severity	CVSS Score	Remediation SLA	Escalation Path
Critical	9.0 - 10.0	72 hours	Immediate Security Ops, CISO notification
High	7.0 - 8.9	14 days	Security Engineering lead
Medium	4.0 - 6.9	30 days	Owning team
Low	0.1 - 3.9	90 days	Owning team, prioritized in backlog
Informational	N/A	Best effort	Documentation only

7.3 Vulnerability Remediation Workflow

Step 1: Triage and Validation 1.1. Security Operations receives vulnerability alert 1.2. Validate finding is not false positive 1.3. Determine affected systems and potential impact 1.4. Assign severity based on CVSS and contextual risk

Step 2: Assignment and Tracking 2.1. Create tracking ticket with severity, affected systems, and SLA 2.2. Assign to appropriate remediation owner 2.3. Notify stakeholders per severity level

Step 3: Remediation 3.1. Develop and test fix in non-production environment 3.2. Implement emergency change for critical, standard change for others 3.3. Deploy fix to production

Step 4: Verification 4.1. Rescan affected systems to confirm remediation 4.2. Close tracking ticket with evidence 4.3. Document lessons learned for recurring issues

7.4 Patch Management

System Category	Patching Window	Testing Requirement	Rollback Plan
Operating Systems	Weekly maintenance window	Staging validation	Snapshot restore
Container Base Images	Continuous rebuild	CI/CD pipeline validation	Previous image rollback
Application Dependencies	With application releases	Full regression testing	Version rollback
Database Engines	Monthly maintenance window	Staging validation + backup	Point-in-time recovery
Network Devices	Quarterly	Lab environment validation	Configuration rollback

7.5 Vulnerability Metrics (FY2025 Actuals)

Metric	Target	Actual	Status
Critical MTTR	72 hours	54 hours	Exceeds target
High MTTR	14 days	9.2 days	Exceeds target
Medium MTTR	30 days	22 days	Exceeds target
Vulnerability backlog (High+)	0	0	On target
Scan coverage	100%	100%	On target
False positive rate	< 10%	7.3%	Exceeds target

---

Security Operations and Monitoring

8.1 Security Operations Center

Acme Cloud operates a Security Operations Center (SOC) providing 24/7/365 monitoring and response capability.

SOC Function	Coverage	Staffing Model	Escalation Path
Alert monitoring	24/7/365	Follow-the-sun (3 regions)	Tiered escalation
Incident response	24/7/365	On-call rotation + SOC analysts	CISO for SEV1
Threat intelligence	Business hours + on-call	Dedicated analyst	Security Engineering
Forensics	On-demand	Specialized team	Legal coordination

8.2 Security Information and Event Management (SIEM)

Acme Cloud aggregates security telemetry in Datadog SIEM:

Log Source	Retention (Hot)	Retention (Archive)	Use Case
Application logs	30 days	1 year	Error analysis, behavior anomaly
Infrastructure logs	30 days	1 year	Configuration changes, resource access
Security event logs	90 days	7 years	Incident investigation, compliance
Authentication logs	90 days	7 years	Access auditing, compromise detection
Network flow logs	14 days	1 year	Network forensics, lateral movement
WAF logs	30 days	1 year	Attack analysis, rule tuning

8.3 Detection and Alerting

Detection Category	Detection Method	Alert Threshold	Response SLA
Brute force attacks	Failed authentication threshold	10 failures in 5 minutes	15 minutes
Credential stuffing	Distributed login patterns	Anomaly detection	30 minutes
Data exfiltration	Unusual data transfer volume	2 standard deviations	30 minutes
Privilege escalation	Unauthorized admin actions	Any occurrence	15 minutes
Malware execution	EDR behavioral detection	Any detection	15 minutes
Lateral movement	Unusual internal connections	Anomaly detection	30 minutes
Configuration tampering	Unauthorized IaC changes	Any occurrence	15 minutes

8.4 Threat Intelligence Program

Acme Cloud maintains a threat intelligence program to proactively identify risks:

Intelligence Source	Update Frequency	Integration
Commercial threat feeds	Real-time	SIEM correlation rules
Industry ISACs	Weekly	Analyst review, indicator import
Vendor security bulletins	As published	Vulnerability management integration
Internal honeypots	Continuous	Automated indicator extraction
Bug bounty program	Continuous	Vulnerability pipeline

---

Incident Response

9.1 Incident Classification

Severity	Definition	Example	Response Time	Customer Notification
SEV1 - Critical	Confirmed data breach, complete service outage	Customer data exfiltration, ransomware	Immediate	Within 24 hours
SEV2 - High	Service compromise, significant degradation	Unauthorized access, partial outage	1 hour	Within 48 hours
SEV3 - Medium	Contained security event	Blocked attack, limited impact	4 hours	As warranted
SEV4 - Low	Minor security anomaly	Policy violation, false positive	24 hours	Not required

9.2 Incident Response Process

Phase 1: Detection and Identification (SLA: 15 minutes for SEV1/2)

1. Alert triggered via monitoring systems
2. SOC analyst performs initial triage
3. Severity classification applied
4. Incident ticket created with initial details
5. Incident commander assigned for SEV1/2

Phase 2: Containment (SLA: 1 hour for SEV1)

1. Immediate containment actions executed (isolation, blocking)
2. Evidence preservation initiated
3. Impact assessment conducted
4. Stakeholder notification per severity
5. Customer communication drafted if required

Phase 3: Eradication (Variable based on incident)

1. Root cause identified
2. Malicious artifacts removed
3. Vulnerabilities remediated
4. Additional detection deployed
5. Verification scanning completed

Phase 4: Recovery (Variable based on incident)

1. Systems restored from clean state
2. Monitoring enhanced for recurrence
3. Normal operations resumed
4. Customer communication sent if affected
5. All-clear notification to stakeholders

Phase 5: Post-Incident (SLA: 5 business days)

1. Post-incident review conducted
2. Timeline and root cause documented
3. Lessons learned identified
4. Improvement actions assigned
5. Incident report finalized

9.3 Customer Notification Commitments

Notification Trigger	Timeline	Communication Method	Content
Confirmed breach of customer data	24 hours	Email to admin contacts, in-app banner	Nature of incident, data affected, remediation
Service compromise (no confirmed exfiltration)	48 hours	Email to admin contacts	Nature of incident, containment actions
Regulatory-required notification	Per regulation (typically 72 hours)	Formal notice	Required disclosures
Scheduled maintenance	5 business days advance	Email, status page	Maintenance window, expected impact

9.4 Incident Response Testing

Exercise Type	Frequency	Participants	Objectives
Tabletop exercise	Quarterly	Cross-functional leadership	Decision-making, communication
Technical simulation	Semi-annually	Security Operations, Engineering	Detection, containment procedures
Full-scale exercise	Annually	All teams including executive	End-to-end response, customer notification
Purple team engagement	Annually	Security + third-party red team	Detection gaps, control effectiveness

---

Business Continuity and Disaster Recovery

10.1 Business Continuity Objectives

Service Tier	RTO	RPO	Availability Target	DR Region
Core Platform (API, UI)	4 hours	1 hour	99.9% monthly	eu-west-1
Data Processing	8 hours	4 hours	99.5% monthly	eu-west-1
Reporting/Analytics	24 hours	24 hours	99.0% monthly	Best effort
Internal Systems	48 hours	24 hours	99.0% monthly	N/A

10.2 Disaster Recovery Architecture

Component	Primary	DR	Replication Method	Failover Type
Database	RDS Multi-AZ us-east-1	RDS Read Replica eu-west-1	Asynchronous (< 1 minute lag)	Manual promotion
Object Storage	S3 us-east-1	S3 eu-west-1	Cross-region replication	Automatic
Application	ECS us-east-1	ECS eu-west-1 (scaled down)	IaC deployment	Route 53 failover
Secrets	Secrets Manager us-east-1	Secrets Manager eu-west-1	Cross-region replication	Automatic
DNS	Route 53 Global	Route 53 Global	N/A (global service)	Health check failover

10.3 Backup and Recovery

Data Type	Backup Frequency	Retention	Testing Frequency	Recovery Procedure
Database (full)	Daily	90 days	Quarterly restore test	Point-in-time recovery
Database (transaction logs)	Continuous	90 days	With full restore test	Log replay
Object storage	Versioning enabled	90 days	Quarterly sample recovery	Version restoration
Configuration (IaC)	Every commit	Indefinite (Git)	With each deployment	Git revert + deploy
Secrets	Automatic replication	N/A	Quarterly validation	Secrets Manager restore

10.4 DR Testing

Test Type	Frequency	Scope	Success Criteria
Backup restore validation	Quarterly	Sample database and file restore	Data integrity verified
DR failover (partial)	Semi-annually	Single service failover	Service restored within RTO
DR failover (full)	Annually	Complete region failover	Platform restored within RTO
Communication test	Quarterly	Stakeholder notification	All contacts reached

---

Third-Party Risk Management

11.1 Vendor Classification

Tier	Criteria	Assessment Requirement	Review Frequency
Critical	Processes customer data, single point of failure	Full security assessment, SOC 2 required	Annually
High	Accesses production systems, processes internal data	Security questionnaire, SOC 2 preferred	Annually
Medium	Accesses internal systems, no production	Security questionnaire	Every 2 years
Low	No system access, public information only	Standard due diligence	Contract renewal

11.2 Vendor Assessment Process

Step 1: Initial Screening 1.1. Business sponsor submits vendor request 1.2. Security classifies vendor tier 1.3. Conflict of interest and sanctions screening

Step 2: Security Assessment 2.1. Security questionnaire distributed (SIG Lite for standard, full SIG for critical) 2.2. SOC 2 report review (where available) 2.3. Technical security review (for integrations) 2.4. Findings documented and risk rated

Step 3: Risk Acceptance 3.1. Findings reviewed with business sponsor 3.2. Remediation requirements or risk acceptance determined 3.3. Contractual security requirements confirmed 3.4. CISO approval for High/Critical vendors with material findings

Step 4: Ongoing Monitoring 4.1. Continuous monitoring for security incidents 4.2. Annual reassessment per tier requirements 4.3. Contract renewal security review

11.3 Subprocessor Management

Current subprocessor list maintained at /subprocessor-list.

Subprocessor Category	Count	Assessment Status	Notification Process
Infrastructure (AWS, Cloudflare)	2	Annual SOC 2 review	30-day advance notice
Data Processing (Analytics, support)	5	Annual questionnaire	30-day advance notice
Security Tools	4	Annual SOC 2 review	30-day advance notice
Business Tools (no customer data)	8	Risk-based review	N/A

---

Compliance and Audit

12.1 Current Certifications and Attestations

Certification	Scope	Status	Renewal
SOC 2 Type II	SaaS platform (Security, Availability, Confidentiality)	Active	Annual
ISO 27001	Information Security Management System	In progress (Q3 2026 target)	Annual surveillance
CSA STAR Level 1	Cloud security self-assessment	Planned (Q4 2026)	Annual
HIPAA	BAA customers	BAA available	N/A (contractual)
GDPR	EU data subjects	Compliant	Continuous

12.2 Audit Calendar

Audit Type	Auditor	Timing	Duration	Output
SOC 2 Type II	Deloitte	Q4 annually	4 weeks	SOC 2 report
ISO 27001 Stage 2	BSI	Q3 2026	2 weeks	Certification
Penetration test	NCC Group	Q3 annually	2 weeks	Executive summary
Internal audit	GRC Team	Quarterly	Ongoing	Finding reports
Privacy impact assessment	Privacy Engineering	Per material change	Variable	PIA report

12.3 Evidence Collection and Management

Evidence Type	Collection Method	Retention	Access
Policy documents	Document management system	Indefinite	GRC team, auditors
Access review records	PAM tool exports	7 years	GRC team, auditors
Change records	Jira + GitHub	7 years	GRC team, auditors
Training completion	LMS exports	7 years	GRC team, auditors
Vulnerability scans	Security tool exports	3 years	Security team, auditors
Incident records	Incident management system	7 years	Security team, auditors

---

Customer Security Features

13.1 Security Controls by Plan

Feature	Free	Professional	Enterprise
MFA enforcement	Available	Available	Available
SSO (SAML/OIDC)	Not available	Available	Available
SCIM provisioning	Not available	Not available	Available
IP allowlisting	Not available	Not available	Available
Audit log access	7 days	90 days	1 year + export
Session timeout configuration	Default only	Configurable	Configurable
Data residency selection	US only	US/EU	US/EU/UK/APAC
Customer-managed encryption keys	Not available	Not available	Available
Custom data retention	Not available	Not available	Available
Security questionnaire support	Self-service	10 business days	5 business days
Architecture review	Not available	Not available	Available
CISO briefing	Not available	Not available	Annual

13.2 Complementary User Entity Controls (CUECs)

Customers are responsible for the following security controls within the shared responsibility model:

CUEC Category	Customer Responsibility	Acme Cloud Support
User access management	Provision/deprovision users appropriately	SSO, SCIM, admin console
Authentication strength	Enforce MFA for users	MFA enforcement setting
Session management	Configure appropriate session timeouts	Configurable timeout settings
Access reviews	Review user access periodically	Audit log access, user export
Integration security	Secure API keys and webhooks	Key rotation, IP restrictions
Monitoring	Monitor audit logs for suspicious activity	Audit log export, SIEM integration
Data classification	Apply appropriate classification to data	Role-based access controls
Incident reporting	Report security concerns promptly	Security contact, in-app reporting

---

Framework Mapping Appendix

SOC 2 Trust Services Criteria Mapping

TSC	Control Area	Key Controls	Evidence
CC1.1	Control Environment	Security policies, organizational structure	Policy documents, org charts
CC2.1	Communication	Security awareness training	Training records
CC3.1	Risk Assessment	Risk assessment process	Risk register, assessment reports
CC4.1	Monitoring	Continuous monitoring, log review	SIEM dashboards, alert records
CC5.1	Control Activities	Access controls, change management	Access review records, change tickets
CC6.1	Logical Access	Identity management, authentication	IAM configurations, MFA enforcement
CC6.6	System Operations	Incident response, backup/recovery	IR records, backup test results
CC6.7	Change Management	SDLC, change controls	Change tickets, deployment records
CC7.1	System Monitoring	Security monitoring, vulnerability management	Scan reports, alert records
CC7.2	Incident Response	IR plan, incident handling	IR plan document, incident records
CC7.3	Recovery	Business continuity, DR	DR test results, backup records
CC7.4	Vendor Management	Third-party risk management	Vendor assessments, contracts

ISO 27001 Annex A Control Mapping

Annex A Control	Acme Cloud Implementation	Evidence
A.5.1 Policies for information security	Information Security Policy, supporting standards	Policy documents
A.5.2 Information security roles	RACI matrix, job descriptions	Org documentation
A.6.1 Screening	Background checks	HR records
A.6.2 Terms and conditions	Employment agreements, NDA	Signed agreements
A.7.1 Asset management	Asset inventory, classification	CMDB, data classification
A.8.1 Access control	IAM policy, access reviews	Access records
A.8.2 Cryptography	Encryption standards	Technical configurations
A.8.3 Physical security	Office security, data center SOC 2	Access logs, vendor reports
A.8.4 Operations security	Change management, capacity planning	Change records, metrics
A.8.5 Network security	Network segmentation, firewalls	Network diagrams, configs
A.8.6 Application security	Secure SDLC, code review	Review records, scan reports
A.8.7 Supplier relationships	Vendor management program	Assessments, contracts
A.8.8 Incident management	IR plan, procedures	IR records
A.8.9 Business continuity	BC/DR plans, testing	DR test results
A.8.10 Compliance	Compliance monitoring, audits	Audit reports

---

Related Trust Center documents

access control, encryption standards, incident response, penetration testing, compliance frameworks, business continuity, third party risk, vulnerability disclosure, backup recovery, data retention

Document revision history

Version	Date	Author	Summary of changes
1.0	2024-06-01	Legal & Compliance	Initial Trust Center publication
2.0	2025-03-15	GRC Program	SOC 2 Type II alignment refresh; expanded subprocessors
2.5	2025-09-01	Security Engineering	Encryption standards update; ISO 27001 mapping
3.0	2026-01-15	Trust Center Program	Full procurement-grade expansion; 34-document set

Contact

Acme Cloud, Inc. 1200 Market Street, Suite 400 San Francisco, CA 94103, USA

Channel	Email	Use case
Trust & procurement	trust@acmecloud.com	Security questionnaires, trust reviews
Security	security@acmecloud.com	Incidents, vulnerabilities, control questions
Privacy	privacy@acmecloud.com	DSRs, privacy assessments
Legal	legal@acmecloud.com	Contractual, DPA, legal notices