The security architecture team designs its standards separately from the enterprise architecture function, and business units complain that security designs ignore their processes and planned changes. What is the BEST way to resolve this?

Security architecture is most effective as an integral view within enterprise architecture, derived from the same business capabilities, processes, information flows and roadmap. Integration means security requirements are traced to business needs, appear in the same models and planning cycles, and are considered when the business plans change rather than after. The complaints from business units are the symptom of that missing traceability. Requiring business units to adapt to standards produced in isolation reinforces the disconnect, increases resistance and encourages workarounds, because the standards do not reflect how the business operates. Letting each business unit design its own security architecture fragments the enterprise view, produces inconsistent controls and leaves shared risks without an owner. Postponing enterprise architecture until security standards are finished reverses the logical dependency: security design should follow from business and enterprise architecture, not the other way round, and the delay would leave planned changes without architectural guidance. Exam caveat: CISM emphasizes alignment of security with business objectives, and the newer architecture content applies that principle to design. Operational check: confirm that security architects participate in enterprise architecture governance, that architecture artifacts carry security views, and that each security standard references the business requirement it supports.