In this writing, we will discuss what function a Cybersecurity Architect plays at an organization and how one can be successful at the role. It should be best understood while reading this that different organizations and people have differing opinions of exactly what job function and responsibilities exist for a certain role. This writing is my opinion after performing the role of a Cybersecurity Architect at one of the largest corporations in the world for several years.
There are many other sites you can find out there that discuss a Cybersecurity Architect, but focus on defining how to get there, how much they make, and/or what certifications to get. This writing is more focused on what a Cybersecurity Architect is like as a person and how they can properly be utilized at an organization.
What is a Cybersecurity Architect?
A Cybersecurity Architect is typically a senior level position within an Information Security function at an organization. It is one of the highest security technical paths someone can take without going into management and is typically on a peer-level of non-Director level management. The role will be discussed throughout this writing (instead of trying to do it in a few sentences), but it can best be explained as an advisory and champion role for the Information Security function.
Some organizations (and people) interchange Cybersecurity Architect and Cybersecurity Software Architect, which is usually just a Software Architect but solely focused on security. A Cybersecurity Architect does not typically work by reviewing code, helping build the code for an application, or anything to do with application design at a code-level, except for a focus on the Software Development Lifecycle (SDLC) process itself to ensure applications are secure.
A Cybersecurity Architects’ function is two-fold, both what I refer to as inward and outward. These functions are performed in some type of percentage that is differing to each organization. For example, an organization with healthy and strong cybersecurity management, engineers, and analysts can afford to let their Cybersecurity Architect be more Outward-focused than Inward. The concern of “too many chefs” should always be maintained.
Inward, by my definition, means to look at what an Information Security function is doing regarding cybersecurity and risk and aiding in that maturation. Some of the common responsibilities:
- Security Engineering: Aiding engineers on their efforts of security technology and process deployment, to include technology discovery input, proof of concept guidance, and overall team guidance.
- Security Operations: Reviewing Security Operations Center (SOC) alerts (at a high, aggregate level) and incidents, specifically reports and lessons learned that are produced to aid in initiatives that will mitigate or prevent those alerts and incidents from happening again.
- Governance: Reviewing Information Security Policies, Standards, and Procedures and potentially being in the line of sign-off on them.
- Risk: Contributing to the risk register and helping prioritize risks and development of plans of actions and milestones to addressing those risks.
- Compliance: Attesting to controls in place throughout the organization by best knowing all the skeletons, which is built by what is learned while being Outward facing.
- Guidance: Helping all Information Security members with mentoring, organizing, teaching, documenting, and guidance.
Outward, by my definition, is the opposite of focusing on Information Security implementations. It involves meeting with business leaders, other Information Technology functions, project managers, vendors, and clients.
When performing this function, the goal is to learn the business. This involves learning what it is your organization does, such as how each business functions and makes money, and then what exists in that business unit from a technology and process perspective. While learning, you maintain both a curiosity hat and a security hat. You should always be asking more questions. If you are an engineer or analyst at heart, that experience and personality-trait will gratefully assist.
While a Cybersecurity Architect is learning the business, including all technology and processes, their goal is to take note of security gaps or concerns (risks) and then raise them appropriately. Is that application considering or implementing access control properly? Is that Software-as-a-Service application generating logs properly and are they being collected? If that system goes down, what happens to your profit-generation? How soon does it need to come back up?
The goal is to be that security champion and aid the business in their success by ensuring they are performing securely.
The Cybersecurity Architect is sometimes closely related to a Security Engineer that is in a Senior or Lead position, but it’s good to understand that while this role has technical knowledge, an Architect should not be clicking buttons in most scenarios. They sit at more of an advisory role and at an equivalent level to the managers of those engineers.
Typically, a Cybersecurity Architect is reporting directly into some designated Associate Director or Director level position. However, it is best to mature the architecture function to directly contribute to a CISO, by establishing a Director/Associate Director/Manager of Cybersecurity Architecture. This helps directly feed into the efforts of the entire Information Security function to ensure the CISO is best informed and guided by both people leaders and technical leaders.
How does one get to a Cybersecurity Architect role? How do they move on from it? These answers are always going to be heavily opinionated, but I will try to answer it in the way I think you can end up most successful. Some will get there faster or slower than you or through completely different avenues, but you should want to focus on being successful in the role, not the velocity or path to get there.
As you saw above in the Inward/Outward sections, a Cybersecurity Architect plays within many functions. Everything in the digital world involves security. In my role, I’ve touched and will continue to touch Security Technology and Processes (Data Loss Prevention, Identity, Endpoint Detection and Response, SOC, Vulnerability Management, Firewalls, etc.), On-Prem Resources and Cloud Resources (Windows, Linux, Mac, etc.), Systems Engineering (including Configuration Management), Networking (Switching, Routing, Load Balancing, Protocols, etc.), Infrastructure-as-Code, SDLC, Storage, Containers, Program and Project Management, Vendor Relationships (including assessments and implementation), Risk Management, Collaboration and Communication Platforms (Email, Teams, Slack, JIRA, Confluence, Miro, etc.), Bring-Your-Own-Device, Encryption, Machine Learning, Telephony, Databases, and so much more. For this reason, it is why Cybersecurity compensates well but demands equally. You are not just a Networking person that only has to know Networking. You need to know that person’s skills PLUS everyone else’s.
As you can see below, in my continued posting of varying topics on Twitter, even Daniel Stefaniak (@d0m3l) wonders if there is anything I do NOT dabble in.
“The goal is to understand, not always know.”Frank McGovern
As stated early on, a Cybersecurity Architect “is one of the highest security technical paths someone can take without going into management”. It’s not something you should feel you can rush into or should want to rush into. You should be ready to ensure you understand technology well and can face the proposed challenges. That’s not to say you need to know it all. 18 months ago, I made a transparent post about my own gaps at the time. Some of these, I still would not consider myself well-versed in. I will never call myself an Expert in any field. The value I have though, is that I can understand how things work, the function they perform, the risks they have, and who can be the expert in the room. There is way too much out there to know it all. The goal is to understand, not always know.
Always challenge anyone that calls themselves an Expert in Cybersecurity, because this is what our field holds. Many can be well-versed in a majority or all of these components, but I doubt anyone is a master of every one of them.
Most technology has the same concerns, you just need to learn enough about the technology to understand the nuances. The major concerns all fall under the common areas of Authentication, Authorization, and Audit (AAA), and then Confidentiality, Integrity, and Availability (CIA). I’m sure you’ve heard these before. It’s not anything groundbreaking and you can become a Cybersecurity Architect. The biggest hurdle is time, because experience will pay off. It’s the nuances and minutia that takes time to better understand and that will make one a better Cybersecurity Architect.
That is how you path up to a Cybersecurity Architect. Now how do you move on from it?
Working Yourself Out of the Job
When posting publicly that I was going to work on this writing, one of the questions proposed was “What’s the best way to work yourself out of the job?” by @TrainofError on Twitter.
I think the best way to perform this, if you want to, is to apply what is listed below in the Personality, Continuous Learning, and People sections. More to come there. However, I think a Cybersecurity Architect is in a perfect position to make pivotal career choices. They can either continue on the technical track, by moving up to things like Senior or Principal roles, or they can consider the – usually – lateral movement to management. That is a personal decision, but you can leave the role successfully or move up within it by continuing to read and apply what myself and others say. I don’t think an organization should remove the role once they have had it, but I think it should be a passthrough role for many. It offers the right balance of technical and advisory and perfectly primes someone to be a leader in the cybersecurity space.
When is it Time For My Organization to Have a Cybsecurity Architect?
To discuss how an organization can properly utilize a Cybersecurity Architect and maintain it as that passthrough leadership role though, we must first discuss how to determine the best time to create the role.
If your organization is finding itself experiencing the following symptoms, it may be time to create that job description and build the role.
- Technical Debt
- Overlapping Technologies
- High Unexplainable Spend
- Immature Cybersecurity Roadmap and Maturity
- Immature Business Engagement with Cybersecurity Risk Concerns
- Improper Alignment to Business or Other IT Functions
These are not all the concerns that could exist, but are Key Risk Indicators (KRI’s) that an organization desperately needs an organized architectural function, which includes a specialized focused role in Cybersecurity Architecture.
If you are needing your CISO to lead and report, managers to manage, your engineers to click buttons, and your analysts to monitor, but need more drivers towards understanding risk, developing a methodical roadmap, and ensuring the business is engaged and aligned … say hello to a Cybersecurity Architect.
This section is about your personality, not others (or what you as an organization should look for in a Cybersecurity Architect). For others’ personalities, see the People section. We’ve talked a bit about where you should come, where you should go, and what does “ready” mean. We’ve prepared you for “What is and how can I become a Cybersecurity Architect.” This section and the following sections are now a focus on “How can I be a successful Cybersecurity Architect?”
The biggest advice I can give is to be approachable and understand balance. You are not always right. No one knows it all. Everyone is equal and you are not above anyone else. One of the best ways to be approachable is to practice listening and understanding Quiet Listening vs Loud Listening as discussed in Kim Scott’s book, Radical Candor, in the section titled ‘Drive Results Collaboratively.’ Many refer to Kim Scott’s book as built for managers, but I think it’s built for anyone that wants to lead, and Cybersecurity Architects have to do a lot of leading. Initiative is a massive trait to have honed in by the time you are in the role.
Seek out others. Seek out learning (see section). No one is going to create meetings with you, until you are seen as a top resource that they respect. That takes time to earn, as it should.
The role is to find risks and move them in the right direction of being less of a risk. Not ignore them or wait until someone else asks or tells you what to do about them. A good Cybersecurity Architect maintains finds a risk, highlights the risk, gives opinions on how to handle the risk, and then maintains persistence on that risk until it is at a satisfactory level.
As is all things in life, one must strike balance. A common balance identified in this space is one of productivity versus security. When you are being an Outward Cybersecurity Architect, you must listen to the business and what their concerns are. You cannot become too defensive of your positions and must continually adapt to new information being provided. You must also understand when the risk mitigation improperly outweighs the risk. Perfect security is a fallacy and it never makes sense to implement a $1,000,000 control for a $10,000 risk. Accepting a risk is a perfectly reasonable response given the right conditions – the same as mitigating, transferring, or avoiding.
One of the hardest things for many in Information Security is this notion of “let things fail.” This is advice I give to many people, and it is usually difficult for them to grasp. Let things fail doesn’t mean let things burn to the ground or let people drown themselves. It means that sometimes someone or something is being a compensating control and that makes it difficult for others to see risk. As a Cybersecurity Architect, you must find the right line of when individuals are ignoring or ignorant to a risk and knowing when you can let it fail, gracefully, to bring awareness. This is a fine skill that takes mistakes and time to learn. There is only so much time in a day, days in a week, weeks in a month, and months in a year. One will burn themself out trying to prevent every risk.
Another strong notion of handling a path forward is consistent checks and balances that things are falling into analysis paralysis.
Analysis paralysis describes an individual or group process where overanalyzing or overthinking a situation can cause forward motion or decision-making to become “paralyzed”, meaning that no solution or course of action is decided upon within a natural time frame.
Often, individuals find themselves overanalyzing a situation (a risk) and getting caught into analysis paralysis and then never move forward. Earlier, I stated that a good Cybersecurity Architect should continually asks questions. That does not mean indefinite questions. Realize when yourself or other individuals are asking too many questions because you’re really just in a trap of punting the risk down the road instead of handling it.
One thing that can cause a Cybersecurity Architect to fall into Analysis Paralysis is by being the smartest person in the room. This can often hinder progress because you sometimes simply know what to do and can find yourself pontificating, talking down to others, or acting more like a professor, which leads you to lose the room. By inviting those that are smarter than you into the picture, it will not only grow you personally, but will also lead to the best solution and can aid in driving the previously mentioned initiative. It’s hard to always control who will be in the room and maybe you are the smartest one there. If so, enter with humility and also realize when it’s becoming too often … it can be a sign of either promotion or organization change time.
Cybersecurity Architects, as previously mentioned, have to understand many concepts. Any technology that the organization you work for utilizes, and even ones it doesn’t, have to be understood. A reminder to try not to focus on becoming the word “Expert.” Instead, realize the scale of what you have to learn and ensure you can properly scale to that. Cybersecurity Architects, in my experience, more closely follow the “Jack of all trades, master of none” mantra. This will do one well to follow as you can often miss the forest for the trees. A Cybersecurity Architect has to sit at a high-level. Getting into the fine weeds too often means they are not considering the big picture and can be causing improper alignment and/or misconfigurations aplenty.
There is always continuous learning in any architecture position. One cannot rest on current knowledge, also known as their comfort zone. By living in a comfort zone, it can cause innovation to stall. There will always be new technologies. To ensure the right things are happening for the business, those technologies have to be understood. How can a Cybersecurity Architect know the best way to mitigate a risk for the business if they’ve only ever learned one way to do it? Not all organization’s risks are the same, and it requires knowing that context along with old AND new understandings in how to handle them.
If you are finding it hard to keep up technically in an ever-changing digital world, it can often be a sign to start thinking on those pivotal career changes. Maybe a move into management is on the horizon so you can round out your people skills instead and lead others on their own technical growth?
The Day-to-Day Cybersecurity Architect
The following sections will discuss more about what a day is like for a Cybersecurity Architect and what will aid you in being successful in the role for those topics. As every organization is different, a reminder that this is my experience and opinions.
So many. Don’t listen to others that say if you’re in too many meetings it means you don’t actually have time to work. A Cybersecurity Architects work is to be talking to others for most of their time. Now and then, there is little direct individual contributor work where you will click buttons or have to lead a project. It can happen, but be ready for days of meetings, as that is a lot of the job.
It’s important in this area to really manage your calendar and develop those time management skills. Block out lunch, block out times before and after your office hours, and block out those times you do need to work on those individual contributor tasks.
Risk is everywhere. Businesses have been handling risks for a long time. Cybersecurity is newer, but risks aren’t. A Cybersecurity Architect’s main function is to find risks, help others see those risks, and then help solve those risks. As you find one, three more will pop up. Understand that it is a never-ending game of cat and mouse. As previously stated verbatim: “There is only so much time in a day, days in a week, weeks in a month, and months in a year. You will burn yourself out trying to prevent every risk and you cannot handle it all alone.”
Many of those meetings a Cybersecurity Architect will sit in is learning a new business application or learning what other IT functions are doing. It’s the time to shine and highlight concerns based on many years of experience and intuition. It’s important to focus on probable threats and not threats that are simply theoretical. Remember … avoid analysis paralysis. If the business can move forward on an initiative and the vast majority of risks are solved, the team should not be overanalyzing outlier risks that have a probability score of almost null. Everyone can find almost an indefinite number of risks for any given scenario. The job isn’t to show off your creative skills and how you’re the smartest person in the room. It’s to identify probable risks, help handle them, and aid the business in moving forward.
A Cybersecurity Architect will spend so much time doing personality management. If you’ve ever thought “I love Cybersecurity, but I’m so fascinated by psychology,” you are in the absolute right profession. Learning personalities of those they work with and those around the business is one of the most important things a Cybersecurity Architect must do. This does also include managing your own personality.
Personality management is imperative to ensure risk is handled appropriately. By being liked, a Cybersecurity Architect will attend more meetings, better garner support of their peers, and appropriately be informed. This allows them to also be a great resource between engineers, operations, and the business. By knowing personalities, a Cybersecurity Architect can help with the approach or ask itself. Simply knowing the right words to use with certain people can make the difference between obtaining a security ally or accidentally derailing an effort.
Often, business units are solutioning in a silo. A Cybersecurity Architect sits at the perfect level lens to see that and highlight it. There have been times when I have seen two different business units creating the same thing or creating something that already exists in another business unit. While this can often more so be a responsibility of an Enterprise Architect, the Cybersecurity Architect is also so well-involved that they can be an aid in these efforts and a part of the relationship building required.
Finally, by learning people around them, it allows for the proper balance as mentioned previously, but especially in choosing battles and doing so with tact. Striking a balance can sometimes mean letting the business move forward with a risk knowing you can push a more concerning risk elsewhere. This constant ebb and flow is crucial to actually improving security maturity.
A common day-to-day event of a Cybersecurity Architect is process enablement or process refinement. And one of the best ways to do that is documentation. A Cybersecurity Architect will be helping with documentation in many places:
- Architectural Diagrams
- Risk Register
- Policy Review
- Standard Review
- Procedure Review
- Vendor/Technology Onboarding or Review
- Gap Analysis
- Information Security Strategy
- Information Security Roadmap
- Incident Response
- Lessons Learned
- Legal Paperwork
While a Cybersecurity Architect is often expected to be in the room giving opinions about technology and ensuring cybersecurity is covered in that technology, they also must actively find risks in processes themselves and how to resolve them.
This topic has been covered a few times in this writing, but I wanted a section here to reiterate the vast landscape of technology that a Cybersecurity Architect may come across and you can’t simply choose to ignore it. You must learn that technology. You don’t need to know it as well as the person in charge of it, but you must at least understand it.
A great resource for things like this is something like that Center for Internet Security’s (CIS) Benchmarks or Well-Architected Frameworks, such as on Microsoft Azure or AWS. You’d be surprised how much can be learned by just studying the cybersecurity aspect of the technology, which will spark your curiosity to learn more about the technology itself. By starting off in the cybersecurity lens of a given technology, you are piquing your interest in cybersecurity before your interest in technology, which will help pull you in. It’s also the proper alignment to be in regarding technology. By at least understanding the technology and the security concerns, you can quickly review how an organization has implemented it for best practice alignment. The goal is to lead a horse to water here. A Cybersecurity Architect’s role is not usually to click buttons, but instead ensure others that do are clicking the right ones.
One thing asked when mentioning this post is of any good books to read. Although my collection of books to read is growing quite large, I unfortunately do not read as many books as I would like to. I have some recommendations, but I would empower others to please comment on this post if you have any recommendations.
Some book recommendations that aren’t specific to being a Cybersecurity Architect, but that I think will teach you more than you realize to be good in the position:
- Radical Candor by Kim Scott
- Extreme Ownership by Jocko Willink and Leif Babin
- The Dichotomy of Leadership by Jocko Willink and Leif Babin
- How to Measure Anything in Cybersecurity Risk by Douglas W. Hubbard and Richard Seiersen
- The Phoenix Project by Gene Kim, George Spafford, and Kevin Behr
- Surrounded by Idiots by Thomas Erikson
- Good to Great by Jim Collins
Thanks for writing this, Frank. It is very insightful.
Hi Frank, Thank you for writing this. It is helpful to me as an aspiring security architect. One opinion I would share is if your org small to medium, a security architect could be more in-demand for hands on keyboard type of work. If the org is large I could see a security architect focusing more on the outward roles you described.