Compliance, Governance and Incident Response

Understanding Compliance Frameworks Without the Jargon

### What SOC 2 actually asks your pipeline to prove **SOC 2** (System and Organization Controls 2) is an auditing framework developed by the AICPA. It is the standard most SaaS companies and cloud-native startups need when enterprise customers ask "how do you protect our data?" SOC 2 is built on five **Trust Services Criteria (TSC)**: * **Security** — are your systems protected from unauthorized access? This covers firewalls, MFA, encryption, vulnerability management, and access reviews. * **Availability** — do your systems meet your uptime commitments? This covers monitoring, incident response, backup, and disaster recovery. * **Processing Integrity** — does your system process data completely and accurately? This covers data validation, change management, and error handling. * **Confidentiality** — is sensitive data protected throughout its lifecycle? This covers encryption, access controls, and data classification. * **Privacy** — do you handle personal data responsibly? This covers data collection policies, consent, GDPR alignment, and retention. Most startups only need the Security criterion. The others are optional unless your customers specifically require them. **Type I vs Type II** is the most important distinction: * **Type I** — a point-in-time audit. The auditor checks whether your controls are designed correctly as of a specific date. Takes 2-4 weeks to prepare. * **Type II** — an audit over a period of time, usually 6-12 months. The auditor tests whether your controls operated effectively throughout that period. This is what enterprise customers actually require. > 📌 **Remember:** SOC 2 Type II requires an observation period. You cannot get a Type II report on controls you implemented last week. Start collecting evidence from day one of implementing a control — not after an audit is scheduled. **What evidence looks like for a DevOps team:** The table below maps SOC 2 Security controls to the engineering artifacts that satisfy them: | SOC 2 Control | What the Auditor Checks | Engineering Evidence | |:---|:---|:---| | Logical access controls | Only authorized users access production | IAM access logs, PR review records | | Multi-factor authentication | MFA enabled for all production access | AWS CloudTrail MFA events | | Change management | All changes reviewed before deployment | GitHub PR history with approvals | | Vulnerability management | CVEs identified and remediated | Trivy scan reports, Snyk findings | | Incident response | Documented process for handling incidents | Incident tickets, postmortem docs | | Encryption | Data encrypted at rest and in transit | AWS Config rule results, TLS certificates | The key insight from engineers who have been through SOC 2 audits: **your CI/CD pipeline already produces most of this evidence.** PR approvals, pipeline run logs, scan reports, deployment history — these are all audit artifacts. The problem is they are not organized or retained with compliance in mind. ### What ISO 27001 asks for differently **ISO 27001** is an international standard for Information Security Management Systems (ISMS). Where SOC 2 is a report produced by an auditor for your customers, ISO 27001 is a certification your organization earns by building a systematic security management process. The 2022 version has 93 controls organized into four domains: * Organizational controls (37 controls) — policies, roles, supplier management * People controls (8 controls) — training, screening, disciplinary process * Physical controls (14 controls) — building security, equipment protection * Technological controls (34 controls) — access control, cryptography, development security The controls directly relevant to a DevSecOps team are in the technological domain. The most important ones for your pipeline: * **A.8.25 Secure Development Lifecycle** — security must be integrated into every phase of development, not added after * **A.8.26 Application Security Requirements** — security requirements must be defined before code is written * **A.8.27 Secure System Architecture** — systems must be designed with security as a default * **A.8.28 Secure Coding** — developers must follow secure coding standards * **A.8.29 Security Testing in Development** — SAST, DAST, and penetration testing must happen before production * **A.8.31 Separation of Development, Test, and Production** — code must not be tested in production > 💡 **Tip:** ISO 27001 auditors are not trying to catch you out. They want to see that you have a systematic process for managing security risks. A documented, imperfect process is better than an undocumented perfect one. Write down what you do before the auditor arrives. **The critical difference from SOC 2:** ISO 27001 requires a **risk register** — a documented list of information security risks, their likelihood, their impact, and the controls you chose to address them. This is not optional. Without a risk register, you cannot get ISO 27001 certified. ### What PCI-DSS adds for payment systems **PCI-DSS v4.0** (Payment Card Industry Data Security Standard) applies to any organization that processes, stores, or transmits payment card data. If your application takes credit card payments, you are in scope. The standard has 12 requirement areas. The ones most relevant to a DevSecOps engineer: * **Requirement 2** — all systems must have secure configurations (no defaults, no unnecessary services) * **Requirement 3** — cardholder data must be protected at rest with encryption * **Requirement 6** — software must be developed securely with vulnerability management * **Requirement 7** — access to system components must be restricted by business need * **Requirement 10** — all access to system components must be logged and monitored * **Requirement 11** — security systems and processes must be tested regularly For Kubernetes workloads specifically, PCI-DSS v4.0 requires: * Pod Security Standards enforced (no privileged containers in CDE namespaces) * Network Policies restricting traffic between pods * RBAC scoped to least privilege * Image scanning with Trivy before deployment * Runtime monitoring with Falco for the cardholder data environment > ⚠️ **Security:** PCI-DSS scope creep is a real risk. Every system that can communicate with your cardholder data environment (CDE) is potentially in scope. Use network segmentation aggressively to keep the CDE boundary small. A smaller scope means fewer systems to audit and secure. ### How to map one control across multiple frameworks simultaneously The most time-efficient compliance approach is to implement a control once and map it to every framework that requires it. The flow looks like this: One technical control implemented | v Mapped to SOC 2 Security criterion | v Mapped to ISO 27001 Annex A control | v Mapped to PCI-DSS requirement | v Single evidence artifact satisfies all three For example, implementing Checkov in your CI pipeline to scan Terraform before apply: * SOC 2: satisfies change management and configuration controls * ISO 27001: satisfies A.8.25 (Secure Development Lifecycle) and A.8.29 (Security Testing) * PCI-DSS: satisfies Requirement 2 (secure system configurations) and Requirement 6 (vulnerability management) One tool, one pipeline stage, three frameworks covered. ---