The enterprise architecture team has started designing a new target-state architecture to support the company's five-year business strategy. At what point should information security be involved?
Select an answer to reveal the explanation.
Short Explanation
It's a lot cheaper to put the plumbing in the blueprint than to rip open the walls later. If you get security into the room from day one, its requirements shape the design instead of fighting it. Every later point on this list is the trap, because each one means retrofitting.
Full Explanation
Enterprise architecture translates business strategy into a structured target state for business processes, information, applications and technology. Security requirements, such as protection of critical information, trust boundaries, identity, resilience and compliance obligations, affect decisions at every one of those layers, so information security should be involved from the start, contributing principles and requirements that shape the design. Early involvement ensures security is traceable to business needs, avoids costly redesign and positions security as an enabler of the strategy. Reviewing the design after approval treats security as a gate rather than a design input; any significant gaps found then require rework and create friction between the teams. Involvement during implementation, after technologies are chosen, limits security to configuring components within an architecture that may already be unsuitable, for example lacking appropriate segmentation or data flow controls. Penetration testing after go-live is a valid assurance activity, but relying on it to introduce security means discovering design weaknesses only when they are most expensive to fix. Exam caveat: involvement stays at the level of principles and requirements; security does not take over architecture decisions. Operational check: confirm security principles are documented in the architecture framework and that a security architect participates in architecture governance reviews.