Document Type: Engineering Checklist / Release Gate
Owner: Engineering Lead
Applies To: All significant changes, new services, new data flows, production-impacting changes
Review Frequency: Annual
Version: 1.0
Purpose
This checklist provides a consistent method to verify that secure-by-design and privacy-by-design principles have been applied before a significant change is deployed to production.
Scope
Required for:
New services, components, or microservices
New public endpoints or API routes
Changes to authentication, authorization, encryption, or secrets handling
Changes that affect data storage, processing, or retention
Infrastructure-as-code or network/security controls changes
Major dependency upgrades or security-related fixes
Instructions
The change author completes Sections A–C.
The reviewer validates and confirms items during code review.
The Engineering Lead performs a final approval for high-risk or production-critical changes.
Checklist
A. Change Summary (Author)
| Item | Response |
|---|---|
| Title / PR link | |
| Owner / author | |
| Components impacted | |
| Risk level (Low/Medium/High) | |
| Production impact expected | |
| Rollback plan documented (Y/N) |
B. Secure-by-Design Controls (Author + Reviewer)
| Control | Check | Notes |
|---|---|---|
| Attack surface minimized (ports, endpoints, features) | Yes / No / N/A | |
| Secure defaults applied (deny-by-default, least access) | Yes / No / N/A | |
| Least privilege enforced (roles, service accounts, tokens) | Yes / No / N/A | |
| Defense in depth applied (multiple controls, not single-point) | Yes / No / N/A | |
| Failure modes are secure (deny on error, no insecure fallback) | Yes / No / N/A | |
| Internal services treated as untrusted (validation/authorization) | Yes / No / N/A | |
| Separation of duties enforced (peer review, controlled deploy) | Yes / No / N/A | |
| No reliance on obscurity for security | Yes / No / N/A | |
| Security kept simple (no custom crypto, proven patterns) | Yes / No / N/A | |
| Security issues fixed with root cause and regression prevention | Yes / No / N/A |
C. Privacy-by-Design Controls (Author + Reviewer)
| Control | Check | Notes |
|---|---|---|
| Data minimization applied (only necessary data collected/stored) | Yes / No / N/A | |
| Privacy defaults applied (logging redaction, limited retention) | Yes / No / N/A | |
| Privacy embedded in architecture (tenant boundaries, access controls) | Yes / No / N/A | |
| End-to-end protection validated (at rest + in transit + deletion) | Yes / No / N/A | |
| Transparency maintained (documented data flows and access points) | Yes / No / N/A | |
| User-centric privacy impacts considered (access boundaries respected) | Yes / No / N/A |
D. Security Testing and Verification (Author + Reviewer)
| Verification | Check | Evidence / Links |
|---|---|---|
| Static analysis / SAST executed | Yes / No / N/A | |
| Dependency scanning executed | Yes / No / N/A | |
| Critical/High findings resolved or justified | Yes / No / N/A | |
| Applicable tests executed (unit/integration/e2e) | Yes / No / N/A | |
| Secrets management verified (no secrets in code) | Yes / No / N/A | |
| TLS and encryption controls verified (where applicable) | Yes / No / N/A | |
| Logging avoids sensitive payloads | Yes / No / N/A |
E. Approvals
| Role | Name | Date | Approval |
|---|---|---|---|
| Peer Reviewer | Approved / Changes requested | ||
| Engineering Lead (High risk / major releases) | Approved / Changes requested |
Exceptions
If any item is marked “No,” the PR must include either:
a remediation plan with timeline, or
compensating controls approved by the Engineering Lead.
Document Control
Version 1.0 — Owner: Engineering Lead — Next Review: 12 months