Security requirements for a new customer portal were added during user acceptance testing, causing rework and a delayed launch. What should the information security manager do to prevent this on future development projects?
Select an answer to reveal the explanation.
Short Explanation
Adding plumbing after the walls are finished means tearing out drywall. Security works the same way: the earlier you put it in the plan, the cheaper it is. The trap is extending testing; that just finds the same late surprises with more time on the clock.
Full Explanation
Security requirements belong at the start of the development life cycle, alongside functional and business requirements, so that they shape architecture, design and build decisions. Defining them early, based on the data and risks the system will handle, avoids discovering mandatory controls during acceptance testing, when changes require redesign, recoding and retesting and threaten launch dates. A longer security testing window before release still discovers requirements at the end and simply budgets more time for the same rework; testing verifies that requirements were met but cannot replace defining them. Testing after go-live and fixing in later releases knowingly exposes customers to weaknesses in production and shifts risk acceptance onto the business without a formal decision. Having the security team rewrite code after development ends is costly, creates ownership confusion and is not sustainable across projects; developers must build to requirements they know in advance. Exam caveat: CISM views integrating security into the life cycle as a program responsibility, typically through mandatory requirement checkpoints in the organization's project methodology. Operational check: confirm that project templates include a security requirements step signed off before design, and track how many security findings are raised at acceptance testing on each project.