Secure development and change: the clause the question tests
How the software is built and changed so that security is checked before release.
How the customer usually asks it
example"Do you follow a secure software development lifecycle, including code review before release?"
Anchor clauses
3 frameworks| Framework | Anchor clause |
|---|---|
| ISO/IEC 27001:2022 | 8.25 Secure development life cycle |
| SOC 2 (Trust Services Criteria) | CC8.1 Change management processes are in place |
| SIG (Shared Assessments) | domain I Application Security |
Every framework that anchors this family is listed here; a register shows the ones ticked for the customer.
Evidence expected
The secure development standard, a sample of recent changes with review and approval records, and the security testing run in the pipeline.
The clauses, with what an assessor asks for
ISO 27001 8.25 Secure development life cycleEstablish and apply rules for secure development of software and systems.
Where answers usually fall short: Policy exists but not enforced; Threat models not updated for new features
Source: ISO/IEC 27001:2022
SOC 2 CC8.1 Change management processes are in placeNamed, not quoted: the criteria text is not held in full here.
Where answers usually fall short: Emergency changes used routinely, with retrospective approval that is never withheld; Approval and implementation performed by the same person, so the approval is not independent
Source: SOC 2 (Trust Services Criteria)
SIG domain I Application SecurityWhat it asks for, in one line (the standard's own text is not quoted here):
Apply secure software development lifecycle practices including secure coding standards, code review, vulnerability testing, dependency management, and pre release security gates.
Where answers usually fall short: No dependency scanning for open source components; Findings closed without retest
Source: SIG (Shared Assessments)