#Compliance Readiness

tsdevstack implements a security-first architecture across all three cloud providers. The framework enforces encryption, network isolation, zero-credential runtimes, and environment separation as non-optional defaults — not configurable afterthoughts.

This page maps the framework's built-in security controls against major compliance frameworks to help teams understand what's covered out of the box and what remains their responsibility.

Bottom line: tsdevstack provides all the technical infrastructure controls required by SOC 2, GDPR, and ISO 27001. Every technical requirement — encryption, network isolation, access control, audit logging, secrets management — is handled by the framework across all three providers. What remains is purely organizational: writing policies, conducting audits, and establishing review processes. The infrastructure is ready; the paperwork is yours.

#Security Controls

#Encryption

All encryption is enforced by default. There are no flags to disable it.

#Network Isolation

Services never run in public subnets. Databases and caches have no public endpoints. Environment isolation is enforced by the framework — you cannot reuse credentials across environments.

#Identity & Access Management

Zero credentials are stored in containers. Runtime authentication uses cloud-native identity (Service Accounts, IAM Roles, Managed Identities). CI/CD uses OIDC federation — no long-lived secrets in GitHub.

#Container Security

#Secrets Management

#OWASP Compliance

The optional auth service template aligns with OWASP security guidelines across authentication, session management, and cryptographic storage:

#OWASP Top 10 Coverage

#OWASP Cheat Sheet Alignment

Note: The auth service is an optional template. Projects that use it get these controls out of the box. The infrastructure-level controls (WAF, encryption, network isolation) apply to all tsdevstack projects regardless of the auth template.

#Compliance Framework Mapping

#SOC 2 Type II

Every SOC 2 technical control listed above is enforced by default. The remaining requirements — formal change approval workflows, access review cadence, incident response playbooks — are organizational processes that vary by company and don't require infrastructure changes.

#GDPR (Articles 25 & 32)

GDPR technical measures (Articles 25 and 32) are fully covered. Data subject rights (erasure, portability, consent) are application-level concerns that the framework leaves to the developer.

#ISO 27001 (Annex A)

Every Annex A technical control listed above is enforced by default. ISO 27001 certification additionally requires the Information Security Management System (ISMS) — risk assessments, internal audits, management reviews — which is organizational, not technical. The infrastructure is already compliant.

#What's Covered vs Your Responsibility

#What tsdevstack provides

• Encryption at rest and in transit enforced by default across all three providers
• Zero-credential container runtimes (Managed Identity, IAM roles, Service Account binding)
• OIDC-based CI/CD with no long-lived secrets
• Network isolation with WAF, private subnets, and origin verification
• Environment isolation enforced at the account/subscription/project level
• Per-service secret and database credential isolation
• Non-root containers with vulnerability scanning
• Infrastructure as Code with full audit trail

#What remains (organizational, not technical)

None of the items below require infrastructure changes — the framework has already handled the technical side. These are business processes your team defines:

• SOC 2: Organizational policies, access review processes, incident response plan, vendor management
• GDPR: Data processing agreements, privacy policy, consent management, data subject rights implementation (application-level)
• ISO 27001: ISMS documentation, risk assessments, internal audits, management reviews

#Cross-Provider Comparison

All three providers achieve equivalent security outcomes through provider-native services: