Posts

SOC 2 Type 2 mapping to Secure SDLC Requirements

/in

We started to talk about the SOC2 Type 2 certification and I feel that we neglected it a bit.

I wrote a bit about SDLC, Secure SDLC in particular, but now it is time to bring them together.

 

SOC 2 Type 2 and Secure SDLC — the big picture

SOC 2 Type 2 evaluates whether controls are operating effectively over time (typically 6–12 months). It is not a point-in-time snapshot.

Your SDLC is not an isolated engineering practice — it feeds directly into several Trust Services Criteria (TSC).

All nine Common Criteria map to the SDLC in some way, but they do so at different layers.

CC1 (Control Environment) is the foundation. It is not about code or process — it is about organizational accountability. The auditor checks that your Secure SDLC has a named owner, that the policy carries formal authority, and that security has a defined role in the development organization. Without this, every other control lacks a governance backbone.

CC2 (Communication) requires that developers know the rules. A Secure SDLC policy that exists but was never distributed or acknowledged does not satisfy this criterion. The auditor looks for training records, policy sign-offs, or equivalent evidence that the people making security decisions in each SDLC phase were aware of their obligations.

CC3 (Risk Assessment) maps directly to the Idea and PoC phases. The criterion requires that risks are identified and analyzed before work begins. A threat model, a risk register entry, or a documented security review of the proposed design all serve as evidence. The auditor wants to see that risk was considered as an input to scope decisions, not evaluated after the fact.

CC4 (Monitoring Activities) requires ongoing evaluation of whether controls are working. In SDLC terms this means SAST, DAST, and SCA scans must run regularly, their results must be reviewed, and findings must be tracked to resolution. Running a scan whose results are never acted on does not satisfy CC4.

CC5 (Control Activities) covers the specific rules that govern how code is written and reviewed. Secure coding standards, mandatory peer review, branch protection, and secrets scanning policies all live here. CC5 is about the guardrails built into the development process itself, not just the approval chain around it.

CC6 (Logical Access) runs across the widest range of SDLC phases. It covers who has access to source code, build pipelines, deployment tools, and production environments — and whether that access is appropriate at each phase. PoC access that was never revoked and production credentials embedded in a repository are both CC6 findings.

CC7 (System Operations) requires that running systems can detect and respond to threats. Its SDLC relevance is that logging, alerting, and incident response readiness must be built into the product before it reaches production. If these are treated as post-launch concerns, CC7 is a gap.

CC8 (Change Management) is the criterion most directly owned by the SDLC. Every code change from PoC through EOL must be authorized, reviewed, and traceable. This criterion generates the highest sample volume in a Type 2 audit — typically 20 to 25 change records — and every sampled item needs a complete evidence chain.

CC9 (Risk Mitigation) addresses third-party and vendor risk. In a software development context this means evaluating open-source libraries, SDKs, and external dependencies before they are adopted. Running a dependency scan satisfies part of this, but CC9 specifically requires that a conscious risk decision was documented — not just that a tool ran.

The practical takeaway is that CC1, CC2, and CC9 are the ones most commonly missing from customers who think their Secure SDLC is well covered.

They focus on CC8 (change management) and CC6 (access) but leave governance, communication, and vendor risk undocumented.

 

Summary mapping of SOC2 controls to SDLC

CC Control Name Idea PoC MVP Release EOL SDLC Intersection / Evidence
CC1 Control environment ✓ — — — — SDLC policy with named owner. Security team has formal authority to block releases.
CC2 Communication ✓ ✓ ✓ — — Secure SDLC policy published and acknowledged. Developer training completion records.
CC3 Risk assessment ✓ ✓ — — — Threat model at Idea phase. Risk register updated before PoC scope is confirmed.
CC4 Monitoring activities — — ✓ ✓ — SAST/DAST results reviewed. Recurring vuln scans in prod. Findings tracked to closure.
CC5 Control activities ✓ — ✓ ✓ — Secure coding standards doc. Code review policy enforced. Branch protection rules active.
CC6 Logical access — ✓ ✓ ✓ ✓ Repo and pipeline access logs. Secrets management reviewed. Prod access revoked at EOL.
CC7 System operations — — ✓ ✓ ✓ Logging enabled pre-release. Alerting configured in prod. Incident runbook referenced.
CC8 Change management — ✓ ✓ ✓ ✓ PR records with approvals. Pipeline gates enforced. EOL change ticket required.
CC9 Risk mitigation ✓ ✓ — — — Third-party libraries assessed. OSS license and security risk reviewed before adoption.

 

Practical Checklist — SDLC Evidence by Common Criteria

CC1 — Control environment

SDLC policy with version, date, and named owner. Org chart showing security’s authority. Evidence security can block a release.

CC2 — Communication

Policy acknowledgment log with names and dates. Annual security training completion records. Re-communication evidence if policy changed during the audit period.

CC3 — Risk assessment

Threat model dated before PoC began. Risk register with severity ratings and owners. Security requirements traceable to backlog items.

CC4 — Monitoring activities

SAST and SCA scan reports on a recurring cadence, not one-off. Vulnerability remediation log showing finding, severity, owner, SLA target, and closure date.

CC5 — Control activities

Secure coding standards document. Branch protection configuration blocking direct pushes to main. Secrets scanning active in the repository.

CC6 — Logical access

User access list per environment with roles. Annual access review log. MFA enforcement evidence. Secrets stored in a secrets manager, not in code. Access revocation records for leavers and decommissioned systems.

CC7 — System operations

Logging configuration in place before first production release. Alerting thresholds and escalation paths documented. At least one security alert triaged and recorded during the audit period.

CC8 — Change management

PR records with reviewer names and approval timestamps for every sampled change. Pipeline logs showing tests passed before deployment. Rollback procedure documented. Change ticket for every production deployment including EOL.

CC9 — Risk mitigation

Dependency evaluation process documented. SCA reports showing library risk at adoption and on a recurring basis. Risk acceptance record for each significant new dependency introduced during the audit period.

Secure SDLC and SOC 2 Type 2 — Summary

SOC 2 Type 2 evaluates whether security controls operated consistently over an audit period, typically 6 to 12 months. A Secure SDLC is not a separate compliance workstream. It is the operational mechanism through which most of the Common Criteria are satisfied.

 

All nine Common Criteria (CC1–CC9) have at least one touchpoint in the SDLC. No phase is audit-free.

Idea is the most governance-heavy phase. CC1, CC2, CC3, CC5, and CC9 all apply here. Before a single line of code is written, the auditor expects a threat model, a risk register entry, a policy that developers have acknowledged, and evidence that third-party dependencies were evaluated. Skipping security at this phase creates gaps that are difficult to close retroactively.

PoC is where CC6 findings most often hide. Auditors check whether PoC environments were isolated from production data and whether access granted during PoC was later revoked. CC8 also applies — even exploratory work needs a change record.

MVP is the most evidence-dense phase and where auditors spend the most time. CC4, CC5, CC7, and CC8 all apply. The auditor will sample pull request records, SAST and SCA scan reports, vulnerability remediation logs, and logging configuration. Controls must have operated on every change, not just most of them.

Release is primarily about authorized change (CC8) and least-privilege access to production (CC6). Pipeline logs are strong evidence because they show controls were enforced automatically. A documented rollback procedure satisfies CC7.

EOL is the most commonly under-documented phase. CC6 requires proof that access was revoked. CC8 requires a change ticket for the decommission. CC7 applies if the system handled live data up to shutdown. Data disposal records satisfy C1.2 if confidentiality is in scope.

The controls most frequently missing in practice are CC1 (no named SDLC policy owner), CC2 (policy exists but was never formally acknowledged by developers), CC7 (logging treated as a post-launch concern rather than a release requirement), and CC9 (dependency risk decisions not documented, even when scans were run).

The key principle for SOC 2 Type 2 is consistency. A control that worked 90% of the time is still a finding. Every sampled change needs a complete evidence chain from its originating phase through to deployment or decommission.

The post SOC 2 Type 2 mapping to Secure SDLC Requirements first appeared on Sorin Mustaca’s blog.

Understanding the SOC 2 Certification

/in

Introduction

SOC 2 (Service Organization Control 2) certification is a framework designed by the American Institute of CPAs (AICPA) to help organizations manage customer data based on five Trust Service Criteria: , confidentiality,processing integrity, availability, security and privacy. This certification is crucial for service organizations that store or process customer data in the cloud.

Comparison of Various SOC Certification Versions

SOC 1 (Service Organization Control 1)

  • Focus: SOC 1 is centered around internal control over financial reporting. It is particularly relevant for service organizations that impact their clients’ financial statements.
  • Users: Primarily used by financial auditors and companies that outsource services impacting financial operations.
  • Types: There are two types of SOC 1 reports:
    • Type I: Assesses the suitability of the design of controls at a specific point in time.
    • Type II: Examines the effectiveness of controls over a defined period.

SOC 2 (Service Organization Control 2)

  • Focus: SOC 2 addresses controls relevant to security, availability, processing integrity, confidentiality, or privacy, based on the AICPA’s Trust Services Criteria.
  • Users: Useful for management, customers, regulators, and other stakeholders concerned with information security and privacy.
  • Types: Like SOC 1, SOC 2 also offers Type I and Type II reports, focusing either on the design of controls at a point in time or their effectiveness over time.

Note: There is also SOC 3, but it is out of scope of this article.

 

Who Should Certify?

SOC 2 certification is essential for any organization that handles customer data, particularly cloud service providers, SaaS companies, and data centers.

It’s also relevant for companies in healthcare, finance, and other sectors where data security is paramount.

Why Certify?

Organizations pursue SOC 2 certification to demonstrate their commitment to data security, build customer trust, and comply with industry regulations. It also helps them stand out in competitive markets and avoid the financial and reputational damage associated with data breaches.

What Is Certified?

SOC 2 certification verifies that an organization adheres to robust information security policies and procedures. The certification evaluates five trust service criteria:

  1. Security: Protection of system resources against unauthorized access.
  2. Availability: Accessibility of the system as agreed upon.
  3. Processing Integrity: System processing is complete, valid, accurate, timely, and authorized.
  4. Confidentiality: Protection of confidential information.
  5. Privacy: Collection, use, retention, and disposal of personal information is in line with the organization’s privacy notice.

While some security frameworks like ISO 27001, PCI DSS, TISAX, HIPAA  have rigid requirements, SOC 2 considers that controls are unique to every organization.

Each company designs its own controls to comply with its Trust Services Criteria.

An independent auditor is then brought in to verify whether the company’s controls satisfy SOC 2 requirements.

After the audit, the auditor writes a report about how well the company’s systems and processes comply with SOC 2.

Every organization that completes a SOC 2 audit receives a report, regardless of whether they passed the audit.

There are two types of SOC 2 reports:

  • SOC 2 Type I reports evaluate a company’s controls at a single point in time. It answers the question: are the security controls designed properly?
  • SOC 2 Type II reports assess how those controls function over a period of time, generally 3-12 months. It answers the question: do the security controls a company has in place function as intended?

To choose between the two, consider your goals, cost, and timeline constraints.

A Type I report can be faster to achieve, but a Type II report offers greater assurance to your customers.

 

 

Topics Verified in SOC 2 Certification

1. Security

The Security Criteria are also known as the Common Criteria. They prove that a service organization’s systems and control environment are protected against unauthorized access and other risks.

Security is the only Trust Services Criteria required for every SOC 2 audit. The other criteria can be added to your report scope if your organization chooses, but they are not required to achieve SOC 2 compliance.

These are the security criteria needed for SOC 2:

  • CC1 — Control environment
    Does the organization value integrity and security?
  • CC2 — Communication and Information
    Are policies and procedures in place to ensure security? Are they communicated well to both internal and external partners?
  • CC3 — Risk Assessment
    Does the organization analyze risk and monitor how changes impact that risk?
  • CC4 — Monitoring Controls
    Does the organization monitor, evaluate, and communicate the effectiveness of its controls?
  • CC5 — Control Activities
    Are the proper controls, processes, and technologies in place to reduce risk?
  • CC6 – Logical and Physical Access Controls
    Does the organization encrypt data? Does it control who can access data and restrict physical access to servers?
  • CC7 – System Operations
    Are systems monitored to ensure they function properly? Are incident response and disaster recovery plans in place?
  • CC8 – Change Management
    Are material changes to systems properly tested and approved beforehand?
  • CC9 – Risk Mitigation
    Does the organization mitigate risk through proper business processes and vendor management?

Implementation: Organizations must establish and maintain a set of security controls to protect against unauthorized access. This includes firewalls, encryption, access controls, and intrusion detection systems.

Audit: Auditors examine security policies, test the effectiveness of security controls, and review incident response plans.

Responsibility: Chief Information Security Officers (CISOs) and IT security teams are typically responsible for implementing and maintaining these controls.

2. Availability

Implementation: Ensuring systems are available involves implementing redundancy, disaster recovery plans, and maintaining system performance monitoring.

Audit: Auditors assess the organization’s ability to meet service level agreements (SLAs) and review backup and recovery procedures.

Responsibility: IT operations teams and service managers oversee availability aspects.

3. Processing Integrity

Implementation: Organizations must ensure that data processing is accurate and complete. This includes validating input data, processing logic, and output accuracy.

Audit: Auditors review data processing controls, check for errors, and validate processing integrity.

Responsibility: Data quality teams and IT personnel are responsible for maintaining processing integrity.

4. Confidentiality

Implementation: Protecting confidential information involves data encryption, access controls, and secure storage solutions.

Audit: Auditors evaluate the measures in place to protect confidential data and check compliance with confidentiality agreements.

Responsibility: Data protection officers (DPOs) and compliance teams handle confidentiality matters.

5. Privacy

Implementation: Organizations must adhere to privacy policies that govern the collection, use, and disposal of personal data. This involves data anonymization and consent management.

Audit: Auditors examine privacy policies, consent forms, and data handling procedures to ensure compliance with relevant privacy laws.

Responsibility: Privacy officers and legal teams are responsible for privacy compliance.

Conclusion

SOC 2 certification is a comprehensive framework that ensures organizations adhere to best practices in data security and management.

By certifying under SOC 2, organizations can demonstrate their commitment to protecting customer data, comply with regulatory requirements, and gain a competitive edge in the market.

Implementing and maintaining SOC 2 controls requires collaboration across various teams, including IT, security, operations, and legal departments, to ensure continuous compliance and security.

The post Understanding the SOC 2 Certification first appeared on Sorin Mustaca on Cybersecurity.