1.5 SDLC Methodologies, Change Advisory Boards & CI/CD Pipelines

🎯 Essential Technical Takeaways

• Strict logical and physical separation must be maintained between Development (Dev), Testing (QA/UAT), and Production (Prod) environments.
• Formal change management requires business justification, peer review, documented UAT sign-off, CAB approval, and a tested backout plan.
• Emergency changes utilize temporary vaulted 'Firefighter' accounts with full session logging and retrospective CAB review.
• Modern CI/CD pipelines embed automated SAST, dependency vulnerability scanning, and branch protection requiring peer review.

The Software Development Lifecycle (SDLC) governs the creation, modification, and deployment of enterprise information systems. Regardless of whether an organization uses sequential Waterfall, iterative Agile, or automated DevOps methodologies, internal control standards demand rigorous governance to prevent unauthorized code modifications and operational disruption.

A fundamental ITGC requirement is the strict segregation of environments: Development (where programmers write code), Testing/UAT (where business users and QA engineers validate functionality and performance), and Production (the live operating environment). Developers must never have write or deployment access to production. Production deployments must be executed independently by designated release engineers or automated deployment agents.

Under formal change management governance (AICPA SOC 2 CC8.1), standard changes require: (1) documented change requests; (2) peer code reviews; (3) business User Acceptance Testing (UAT) sign-off; (4) review and approval by a multidisciplinary Change Advisory Board (CAB); and (5) a documented rollback/backout plan. In modern DevSecOps pipelines, these gates are automated: branch protection rules block pull requests until automated SAST scans, SCA dependency checks, and peer approvals succeed.

⚠️ CPA Evolution Exam Traps & Control Pitfalls

• Deploying unvetted code directly into production without staging environment testing.
• Allowing developers to deploy their own code into production environments.
• Copying live, unmasked production databases containing PII into development or testing environments.