What is security architecture?

A newcomer to the ISO27k Forum asked one of those disarmingly simple or naive-sounding questions today, the kind that turn out to be fascinating once we scratch beneath the surface.

"I am currently assigned task to perform security architecture review. Can anyone help me with reference links to start off with?"

It would be inappropriate to offer suggestions and press ahead without first understanding the objectives, expectations and constraints, hence the obvious starting point (from my perspective) would be to figure out what a “security architecture review” is - more specifically, what management (or whoever assigned the task) expects from it e.g.:

• What are its aims/purposes or drivers? 
• Where did it spring from? What triggered it? Why now? Why you?
• Is it business-led or IT or infosec or risk or what? Who is behind it? Who stands to benefit or be affected by it? Who are the stakeholders? Are they supportive and engaged, neutral/unaware, or reluctant and disengaged?
• What is it expected to lead into – if anything? Is the outcome entirely open at this point, depending on what the review finds, or are there pencil marks or proposals on the table already, perhaps secret agendas looking for fuses to light?
• What is the scope? Is it meant to be reviewing all of 'security' (whatever that means), or information security, or cybersecurity, or compliance, or strategy, or assurance, or software development security, or information flows, or something else? And why is that - what determines the scope? Why are some things in and others out of scope?
• And, not least, what is ‘security architecture’, or indeed 'architecture', in the specific context of the organization? In some organizations, architecture is central to strategy, making it the domain of senior, experienced managers, who are unlikely to task a clueless underling to review it. To others, it's about blueprints (literally) showing plan and elevation views, and Crime Prevention Through Environmental Design.

These are not facetious or trivial questions: to my mind, there are lots of possibilities which affect the review substantially - such as its priorities, depth, scope, timescale, assurance and so on. It's basic navigation really:

Before plotting the route, where are we
on the map ... oh and where are we heading? 

For example, a "gap analysis" comparison of the organization’s information risk and security management practices against the recommendations in ISO/IEC27001 and 27002, is one possible approach. But that may not be what the organization is expecting from its "security architecture review" ... and that's not the only interpretation of "gap analysis"!

Another possible approach would be a strategic/high-level review of the organization’s information risk management practices and/or its suite of information security controls, with a strong emphasis on how things are or should develop over the next few years. Are there suitable foundations on which to build a solid ISMS with all the appropriate controls and other risk treatments in place? If not, what are the gaps and how might they be filled-in? Are there, for example, any other business, change, IT or other strategic initiatives on the horizon that might be opportunities to deliver substantial parts of the ISMS, with strong business backing and hopefully the funding to suit?

Yet another possibility is an audit/review of the organization’s current ‘security architecture’, a chance to determine how effective it is and has been, historically, forming the basis for revision, renewed emphasis or simply endorsement going forward. Is the organization poised to align its security arrangements with business objectives, technology trajectories and so forth? 

Those are substantially different approaches, just for starters, based on the forum question. We're some way from answering it at this point!