Skip to content

So, you want to be a Security Architect.

I was speaking with a colleague the other day who is currently working as a cloud security engineer, and he asked me if I thought he was ready to apply for a job as a security architect. I spoke to him about my own journey into cyber security, which started with an early obsession with computers that carried into adulthood. 

But this alone wasn’t enough to crack open the door of the security architecture clubhouse.  I needed real skills and experience, working daily alongside security professionals and learning from them, slowly absorbing knowledge like a sponge.  In my first security job, I was doing my own study most evenings – even though I already had over 10 years of experience in IT, a computer science degree, did programming on the side as a hobby and had just gained one of the first AWS Solution Architect (Associate) certifications in Australia (the professional certification wasn’t released yet).

And even with all that, it still wasn’t enough.  I went for a job as a security architect and bombed the interview – because I wasn’t ready.  I really didn’t know enough.  I just hadn’t spent enough time in the chair.

What is Security Architecture anyway?

Security architecture can mean many things, depending on who you talk to.  I’d define most security architecture work in enterprises today as evaluating proposed IT designs and ensuring they meet the relevant security standards – then identifying areas where the designs are deficient and providing security advice back to the solution designer.  Basically, “architecture design assurance” work.

A smaller population of security architects work to define the security strategy and high-level controls that can be leveraged across the enterprise – usually named “Enterprise Security Architects”.   Some people claim this work is the “real” architecture and anything else is just engineering, but I disagree.  I think both roles perform architecture work, just at different organisational layers.

What skills do you need?

1. Understand the Ones and Zeros

The best security architects have a technical background.  Or, at the very least, fully understand the technical aspects of a solution – and in most cases, could probably build it themselves given enough time.  If you don’t fully understand how a technology works, you can’t perform a threat assessment and derive the security exposures.   You don’t need to know everything about everything, but you need to know enough so that you can’t have the wool pulled over your eyes by the people who are technical. 

You also need to be able to interact with these other technical people and be able to provide concrete examples or evidence that supports your position.  Sometimes you might be the person saying, “Security says no”, and you need to be able to back up that position with supporting evidence – without simply hiding behind the policy.

Or you might encounter the opposite—where your security colleagues say no because they might be the ones blindly applying a specific security policy, but you’re actually saying yes because, in your opinion, the solution has sufficient compensating controls! You then need to be able to explain why the solution is still secure and the organisational data is safe even though it might technically be a policy violation. 

A good security architect knows when the rules can safely be ignored (or ‘risk accepted’) because a specific policy may not apply to your use case. I find this often with SaaS products. The organisation purchases a SaaS product, meaning some security is the SaaS provider’s responsibility. But then your organisation wants to apply its own policies to the solution, which the SaaS can’t meet. If you don’t understand how the technology works, how can you provide advice on how to proceed?

2. Continual Learning

You sort of need to ‘know a lot about a lot’.  I have people reach out to me on a continual basis and ask questions – “Am I allowed to send these log files to our business partners, and what’s the best way to send them?” “Should we use mutual TLS for this integration?” “Does this API need to sit behind a WAF?” “Out of the 10+ identity solutions we have, which one should we use for this specific use case?” “How can we connect Salesforce to our Enterprise email cluster?” “Why can’t we just use local login for that?” are all questions I’ve been recently asked.  Some of these might be easy, and there’s an organisational solution already available – some might require spending millions of dollars to implement properly, but you need to be able to have some sort of answer or at least know how to find the answer quickly.

If somebody is explaining a solution to you, you must be able to quickly understand the solution – so you can perform a threat analysis in your head and offer them advice on whether their solution is secure and complies with policy.  This requires broad knowledge in most areas, but it’s also a good idea to be an expert in a few areas as well.  It’s no longer possible to know everything about everything – there’s too much to know now, but some specialist knowledge in extensively used domains such as cloud, networking or application security helps.

3. Communication and stakeholder influence

Technical and communication skills?  Yes, I know it’s a difficult combination to find, but the best security architects can do both.  You need to break down a technical exposure and communicate it in a way the business can understand.  You might have to work with the risk team to determine the risk of not implementing an entitlement check.  Unfortunately, you can’t just pull up OWASP onto the big screen, drop the mic and walk off stage.  How does this exposure affect the business?  Does it take out a service so they can no longer operate?  Or if this exposure is compromised, will it cause reputational damage? 

The business doesn’t know or care about OWASP.  They just want to know if they can go live or not.

At the enterprise level, influencing stakeholders and convincing them that your idea is a good one becomes more important than your technical proficiency.  You can’t simply publish a document and demand that every product owner in the company connect their system to your new security tool.  That’s not to say you don’t still need those technical skills, however – without them, you won’t be able to come up with the architecture in the first place.

4. Accepting that you’re an advisor

There are many security architects who say ‘no’, point to the policy, and tell people to come back when they’ve designed a new solution. The good news is that I think that’s slowly changing. It’s the SecArch’s job to advise the business on the solution exposures, suggesting additional controls that might be needed and pointing out any residual risk they might need to accept.   

It’s not their job to say yes or no (or if it is, it shouldn’t be).  Many costs go into a program, and many other teams provide inputs into a design – from engineering effort and complexity, ongoing operational cost and impact, hosting costs, SaaS costs and storage, to name a few.  Security, while important, is only one aspect of the solution, and it’s the business sponsor – the person putting up the money – who needs to decide whether to proceed.

And please don’t be the person that nods their head and agrees they’re not the decision maker, but instead rates the cyber security risks so high that it’s a “no by default” because they know the organisation can’t proceed with a risk rated that high.  Rate your exposures or risks appropriately so the business can make an informed decision.


Before stepping into this role, you should know that to be successful, you need extensive technical knowledge across many domains. Even if you’ve been in the IT industry for a while, you might not have the specific security knowledge required to be effective, and that’s okay – you just need to give it time.  And if you don’t know how the zeros and ones work, how can you adequately protect your company’s or client’s data?

Once you have that mastered, you will need to be able to communicate the issues and risks in a language that your stakeholder can understand and resonates with them. A successful security architect must have breadth and depth in cyber security as well as the communications skills and business acumen to be able to articulate the change needed to a diverse range of stakeholders. Sometimes it’s the development team, sometimes it’s the C-suite.

Leave a Reply

Your email address will not be published. Required fields are marked *