In has been my experience that when communicating with software developers to speak about security in the context of software engineering. Express how building secure products is what mature and high performing engineering teams do. For business leaders, it is best to use the language of risk management and finance. This include conveying what is the likelihood that a security incident could occur in the organization based on the risk and the environmental factors upon which the risk exists. Furthermore, include how much financial or productivity losses the organization could experience if the risk were to materialized. Business leaders care about situations that can disrupt the ability for the organization to generate revenue.

On the other hand, there are risks of of leveraging existing frameworks for security architecture: * They may not be tailored to the specific needs of your organization. * They may be too complex and difficult to implement. * They may not be up-to-date with the latest security advances. * They may not be flexible enough to accommodate changes in your organization's business or technology. To mitigate these risks, it is important to carefully select a framework that fits your organization's needs and then tailor it to your specific requirements. You should also make sure that you have the resources and expertise to implement and maintain the framework effectively.

There are *two* different ways to illustrate the risk - and they are complementary: The noted frameworks (I've used NIST/FFIEC for years) help relay what the risk looks like from a maturity/gap perspective. These help drill down into the domains that constitute a complete program - governance, threat understanding, controls, external risk & incident response. But it alone doesn't speak the language that something like FAIR does - where risk is expressed in monetary terms. When presenting to the exec/board level this is the chart that will no doubt grab their attention... then compare what a remediation of the gap(s) looks like from investment against the best/middle/worst-case outcome of, say, a ransomware attack that succeeds.

NIST is by far the most understandable for a broad audience in my opinion, and can be looked up and downloaded with a simple search, which makes it accessible beyond the closed methods of the some of the others.

This collaboration is critical especially in cloud security and cloud-native platforms, where there is a rapid velocity of change and a lot of autonomy by developers who likely have more operational experience than the security team. To avoid security architecture to be too abstract and idealistic, or pose significant operational burden, the dialogue between security architecture and those affected by it should be continuous. I am a strong proponent of weekly Office Hours, where progress can be shared and questions asked and answered. The high frequency ensures the ongoing exchange stays operational and practical. Focus on effective security outcomes and what the organization realistically can absorb and achieve.

Security architects must advocate that the business conduct regular table top scenarios to help the business understand and improve their risk management posture.

The article misses on simplification. It is important to highlight because: - security has had a band-aid approach for years, with lots of point fixes applied that don’t endure the test of time and space (ie various scenarios) - security often comes in the way of work - security has had a tradition of becoming shelf-ware. An important aspect of security architecture is to demonstrate how it simplifies and aligns with business. This itself has a lot of cross appeal that can help with the evangelizing. You could also think of this as a section for: - ease of use, how it kills complexity. - ease of adoption, how it won’t become shelf-ware. - objection handling, why it won’t come in the way.

Make it easy to give feedback with the tools you have or can get access to. There are so many apps in the app marketplace that can assist in this insightful feedback.