Secure SDLC and Threat Modeling for SOC 2

What this control should accomplish

Material designs receive a security review that identifies realistic threats, required safeguards, owners, and accepted residual risks before production release.

How to implement Secure SDLC and Threat Modeling

1. 1

   Define review triggers

   Identify design characteristics that require security review, including new trust boundaries, privileged actions, sensitive data, and material availability dependencies.

   You should end up with: Security-review trigger checklist

2. 2

   Map the design

   Document components, actors, data flows, trust boundaries, dependencies, and security assumptions for the proposed change.

   You should end up with: Current design and data-flow diagram

3. 3

   Analyze threats

   Record plausible abuse cases, affected assets, existing safeguards, required treatments, and an accountable owner for each open item.

   You should end up with: Threat model with tracked findings

4. 4

   Close the review

   Verify required treatments or document time-bound risk acceptance before the change is approved for production.

   You should end up with: Security review decision linked to release

Evidence to keep, and what it should prove

Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.

Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.

Which records should you prepare for the audit?

How an auditor may test this control

Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.

• Confirm the intended control outcome

  Determine whether the control is designed to achieve this result: Material designs receive a security review that identifies realistic threats, required safeguards, owners, and accepted residual risks before production release.

• Confirm ownership and operating cadence

  Compare the documented owner with the intended role (Head of Engineering / Platform Owner), then compare dated records with the stated cadence: Per change.

• Establish the complete audit record set

  Start from deployment and change exports, apply the documented trigger rules, reconcile qualifying items to design and security-review records, and separately account for emergency paths and accepted risks.

• Prepare the as-of-date evidence for a Type 1 engagement

  Retain current security-review triggers and one recent material design showing the threat analysis, review decision, treatments, and any active exception as of the selected date.

• Prepare period evidence for a Type 2 engagement

  Identify every production deployment and approved change during the period that met a documented security-review trigger, including new services, material architecture changes, emergency releases, and releases with risk exceptions; include the completed review or documented trigger assessment.

• Inspect the policy / design artifacts

  Documents that define the control, its scope, ownership, and expected way of working.

  • Inspect Threat models

    For each selected record, confirm it demonstrates The team analyzed credible threats against the actual design and assigned treatment or acceptance decisions before release.

    • Design or change ID
    • Assets and trust boundaries
    • Threats
    • Safeguards
    • Finding owners
    • Review date

• Inspect the approval / review evidence

  Records showing that an accountable person reviewed, approved, challenged, or accepted the work.

  • Inspect design reviews

    For each selected record, confirm it demonstrates Engineering and security reviewers evaluated the proposed architecture, assumptions, data flows, and release conditions.

    • Design version
    • Affected services
    • Reviewers
    • Review date
    • Decisions
    • Open actions

  • Inspect security review records

    For each selected record, confirm it demonstrates A scoped security assessment produced an attributable decision and follow-up work for the production change.

    • Review ID
    • Change scope
    • Reviewer
    • Risk findings
    • Disposition
    • Release linkage

  • Inspect risk exceptions

    For each selected record, confirm it demonstrates Any unresolved design risk was knowingly accepted for a defined scope and period by an authorized owner.

    • Exception ID
    • Risk description
    • Affected release
    • Approver
    • Compensating action
    • Expiry or review date

• Trace the control from design to operation

  Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.

Common implementation and evidence gaps

• Security review begins after implementation, when design changes are expensive.
• The threat model is generic and omits actual data flows or trust boundaries.
• Findings have no owner, due date, or link to release approval.
• Material architecture changes are not consistently identified for review.

Before you call this control ready

• Would the review trigger for a new privileged API or tenant data flow?
• Can each open threat be traced to treatment or documented acceptance?
• Does the diagram match the design that was released?
• Can the team produce completed reviews for recent high-risk changes?

Trust Services Criteria references

These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.

• CC3.2
• CC5.2
• CC8.1

Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.

Related controls to review next