References and scope¶
The checklist is technology-neutral and synthesizes lifecycle governance, product quality, software engineering, secure development, accessibility, software supply chain, identity, incident response, operations, and reliability practices.
Structure rationale¶
The 16-phase sequence follows the whole-lifecycle scope of ISO/IEC/IEEE 12207 and the breadth of the SWEBOK Guide while remaining usable as one navigable review. ISO/IEC 25010 provides a product-quality lens, and NIST SSDF keeps secure development outcome- and risk-oriented. WCAG, OWASP ASVS, NIST AI RMF, and other specialist sources inform triggered domains. The production tracks remain the final assessment of the exact artifact and operating environment.
The sequence is not a prescribed development process. Teams may work iteratively or concurrently and revisit controls when assumptions, architecture, dependencies, data, or release state change.
Standards snapshot¶
The integrated checklist was reviewed on August 15, 2026. Verify current versions and applicability before making the controls a formal engineering or release gate.
- ISO/IEC/IEEE 12207:2026 — software lifecycle processes
- IEEE Computer Society — SWEBOK Guide V4.0 knowledge areas
- ISO/IEC 25010:2023 — product quality model
- NIST SP 800-218 — Secure Software Development Framework 1.1
- OWASP Application Security Verification Standard
- W3C Web Content Accessibility Guidelines 2.2
- SLSA specification 1.2
- NIST SP 800-63 Revision 4 — Digital Identity Guidelines
- NIST SP 800-61 Revision 3 — Incident Response Recommendations
- FIRST CVSS v4.0 implementation guidance
- CISA software bill of materials resources
- Google SRE Workbook — implementing SLOs
- DORA — software delivery performance metrics
- web.dev — Core Web Vitals
- NIST AI Risk Management Framework
- OWASP Artificial Intelligence Security Verification Standard
Frequently triggered legal and regulatory references¶
- EU General Data Protection Regulation
- PCI Security Standards Council document library
- US HHS HIPAA Security Rule resources
- US FTC Children’s Online Privacy Protection Rule
- European Accessibility Act
These links are starting points, not a complete applicability analysis.
Limitations¶
- This project is not legal advice, certification, or a guarantee of security or reliability.
- Controls must be tailored to the application’s users, data, architecture, markets, contracts, and risk.
- A source-code review cannot substitute for production evidence, operating drills, qualified human review, or accountable risk acceptance.
- Standards, laws, threat techniques, provider behavior, and dependencies change over time.
- Some high-risk systems need controls beyond this checklist.
Use the source consolidation manifest to trace the supplied archive documents, import counts, deduplication rules, and archive hashes.
When requirements conflict, document the conflict, obtain qualified review, and record who approved the resolution.