# Secure Development (SDLC) Policy

> **Template — adapt before use.** Replace `[bracketed]` placeholders and have an owner approve it. Not compliance advice.

| | |
|---|---|
| **Owner** | [Role] | **Approved** | [YYYY-MM-DD] | **Review** | Annual | **Version** | 1.0 |

Maps to: ISO 27001 A.8.25–8.29 · SOC 2 CC8.1 · PCI DSS Req 6 · OWASP ASVS.

## 1. Purpose & scope
Defines how [Company Name] builds and ships software securely, from design through deployment.

## 2. Requirements
- **Design:** threat-model significant features; follow secure design principles (least privilege, defense in depth).
- **Code:** follow secure coding standards (e.g. OWASP Top 10); no secrets in code; peer review before merge.
- **Testing:** automated security checks in CI — dependency/vulnerability scanning (SCA), static analysis (SAST), and secret scanning; address findings by severity SLA.
- **Dependencies:** track third-party components (SBOM); patch known-vulnerable dependencies promptly.
- **Environments:** separate development, test, and production; no live sensitive data in non-production.
- **Deployment:** changes follow the _Change Management Policy_; production access is least-privilege.

## 3. Vulnerability remediation SLAs
| Severity | Fix within |
|---|---|
| Critical | [7 days] |
| High | [30 days] |
| Medium | [90 days] |

## 4. Evidence
CI scan results, code-review records, SBOMs, and remediation tickets are reusable audit evidence.

## Revision history
| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 | [YYYY-MM-DD] | [Name] | Initial issue |