SDLC Standard Guide

Requirements, design, build, test, and release controls for engineering teams — CC8 change management.

SDLC policy template SOC 2 preview (SOC-007)
.docx SOC-007

SDLC Standard

Requirements, design, build, test, and release controls for engineering teams — CC8 change management.

How to Fill Out This SDLC Standard

SDLC policy template SOC 2 — Map your real CI/CD and review process to each section. Reference SOC-011 for production change approvals and SOC-012 for code review.

Recommended Owner: Engineering Lead | Security for secure SDLC gates

What this file is for

Document purpose

SDLC standard for secure engineering (CC8).

In your program: Must match real PR reviews, CI/CD, and SOC-011 change process.

Before you start

Getting Started

  • Enable Editing in Word; replace `[` placeholders and delete gray examples.
  • Cross-check names and vendors with SOC-002, SOC-004, and Phase 1 COR policies.

Document tour

Fill out the file section by section

Work through the sections below in order. Each block matches a heading or tab in the downloaded SOC-007 file.

1. Purpose & Scope
  • List repos, APIs, and IaC in boundary — must match SOC-004 Section 3.
  • Delete gray example bullets that do not apply.
2. Development Methodology
  • Document actual process (Agile, trunk-based) and release cadence.
  • After editing 2. Development Methodology, search for `[` placeholders and gray sample names — auditors flag incomplete templates.
3. SDLC Phases & Security Requirements
  • Complete the phase table — each row needs a concrete security gate auditors can sample.
  • Link Build/Test/Deploy to SOC-011 tickets and SOC-012 PR checklist.
4. Secure Coding Guidelines
  • OWASP-aligned rules your team actually follows — cite training (SOC-006).
  • After editing 4. Secure Coding Guidelines, search for `[` placeholders and gray sample names — auditors flag incomplete templates.
5. Dependency & Open Source Management
  • CVE scanning, license review — tie to SOC-016 SLAs.
  • After editing 5. Dependency & Open Source Management, search for `[` placeholders and gray sample names — auditors flag incomplete templates.
6. Environment Separation
  • Prod vs staging; no prod data in lower envs without COR-014.
  • After editing 6. Environment Separation, search for `[` placeholders and gray sample names — auditors flag incomplete templates.
7. Branch & Release Strategy
  • Branch protection, required reviews, CI gates — match GitHub/GitLab settings.
  • After editing 7. Branch & Release Strategy, search for `[` placeholders and gray sample names — auditors flag incomplete templates.
8. Security Training for Developers
  • Secure coding requirement — tracked in SOC-006.
  • After editing 8. Security Training for Developers, search for `[` placeholders and gray sample names — auditors flag incomplete templates.

9. Related Documents

  • SOC-011, SOC-012, SOC-016, COR-009.
  • After editing 9. Related Documents, search for `[` placeholders and gray sample names — auditors flag incomplete templates.

10. SOC 2 Mapping

  • CC8.1/CC8.2 — update when SDLC tooling changes.
  • After editing 10. SOC 2 Mapping, search for `[` placeholders and gray sample names — auditors flag incomplete templates.

Quality check

Before You Finalize

  • Referenced tools (GitHub, CI) match SOC-004 Section 3.

Evidence

Where to Store It

  • Store the completed file in your compliance evidence folder (signed PDF for policies).
  • Register the document in COR-013 with version, owner, and next review date.
  • Link the file from your evidence index or SOC-005 project plan when you use Phase 3 trackers.

Next Steps

After customizing SDLC Standard:

  1. 1Complete the file: Finish every section or tab in SOC-007.
  2. 2Register: Add version and owner to COR-013.
  3. 3Operationalize: Train owners listed in the document.
  4. 4Evidence: Keep exports auditors can sample during fieldwork.