The city’s internal DevOps team is adopting continuous delivery, while a legacy vendor still delivers waterfall releases for a mainframe tax batch system. How should security engage both?

Security engagement must fit the delivery methodology actually in use. For the city’s internal DevOps team adopting continuous delivery, embed security into DevSecOps pipelines—automated SAST/DAST or equivalent checks, dependency scanning, secret detection, policy gates, and rapid remediation loops—so controls match deployment velocity. For a legacy vendor still delivering waterfall releases on a mainframe tax batch system, retain formal security checkpoints at requirements, design, test, and release milestones appropriate to that cadence. Refusing to secure either path until everyone “goes Agile” leaves tax processing and modern apps unprotected during a multi-year transition.

Refusing any security activity until every vendor switches to weekly sprints makes methodology purity a prerequisite for risk management—an unacceptable civic posture. Applying only ad hoc production hacking after each waterfall release and skipping pipeline controls for the internal team leaves both modes without systematic assurance. Assuming Agile teams never need security reviews because velocity replaces risk management confuses speed with safety; DevSecOps exists precisely because fast delivery still needs controls.

Exam caveat: security adapts to waterfall, Agile, and DevOps/DevSecOps contexts rather than demanding a single methodology. Pipeline automation and milestone gates are different mechanisms for the same goal: risk-managed delivery. Mixed environments are normal in government.

Operational check: publish two engagement playbooks—one for CI/CD product teams with pipeline control requirements, one for waterfall vendors with milestone review entry criteria—and audit both the internal tax-adjacent services and the mainframe vendor releases against the matching playbook.