Security only reviews the benefits-eligibility product in a final audit after development is “feature complete,” often rejecting work that citizens were about to use. What should the Product Owner do in the org-design conversation?

Critical cross-functional skills such as security belong in the Scrum Team’s ability to produce a Done Increment of a benefits-eligibility product. When security only reviews in a final audit after “feature complete,” late external audits recreate phase gates, delay Time-to-Market, and turn quality into a surprise that rejects work citizens were about to use. The Product Owner should integrate security skills into the Scrum Team so risk is handled continuously, not only as a late gate. Making security a second Product Owner or parking it after Done merely relocates the gate.

Keeping security outside so Developers are not “slowed” fails because late rejection is slower and costlier than in-Sprint risk work. Scheduling a separate audit Sprint after every release so Done can ignore security fails by inventing a waterfall stage after Done. Asking security to become a second Product Owner for risk items fails by splitting backlog accountability.

Exam caveat: Security belongs in continuous Done, not in a final civic audit surprise. Operational check: Embed or pair security capacity into the eligibility Scrum Team, add security checks to the Definition of Done, and retire the end-only audit as the primary control.