How to Get a Security Architect Job in 2026-27

What a security architect actually does, and the three jobs hiding under one title

A security architect decides how security gets built into systems, usually before those systems exist, and then spends most of the week getting other people to build it that way. The artefacts are designs and decisions: a target-state architecture with the steps to reach it, a reference pattern that five teams can reuse, a design review verdict with conditions, a threat model with the decisions it changed, a standard with an exception process, a one-page brief telling an executive what the risk costs and what the options are. Almost none of it is a change you merge yourself.

That is the part that surprises people arriving from engineering. Your throughput stops being visible. A senior engineer can point at what shipped. An architect's good week looks like three conversations, a diagram, and a document that stopped a team spending two quarters building the wrong thing. The job is judged on whether designs got adopted and whether the ones that shipped held up, both of which take months to become visible.

The second thing to understand is that the title covers three genuinely different jobs, and candidates routinely apply for one and are interviewed for another. The first is design authority inside an engineering organisation: you sit with platform, product and infrastructure teams, you are in projects early, you write the patterns other engineers consume, and your influence comes from being useful rather than from a mandate. The second is the enterprise governance seat: you sit inside a central architecture function or a security governance team, you write standards, you map controls to frameworks, you represent security on an architecture review board, and you may not have production access at all. The third is the vendor seat, where security architect frequently means presales solutions engineering: you design deployments of your employer's product for prospects, and the work is half technical and half sales.

All three are real jobs and all three pay well. They want different evidence. The engineering-adjacent architect is asked to read a Terraform plan and argue about an identity model. The enterprise architect is asked how they would get 40 teams onto a standard and what happens when one refuses. The vendor architect is asked to present to a hostile buyer. Walking in with the wrong preparation reads as weakness rather than as a mismatch, which is why the questions you ask in the recruiter screen matter more in this role than in most security roles.

One more posting type is worth naming, because it is not really architecture at all and it wastes people's time: the advert that says security architect and describes a senior engineer with extra meetings, or a compliance writer with a better title. Neither is dishonest, and either can be the right job, but you should know before the fourth interview. The tell is in the responsibilities. If the posting lists tools you will operate, it is an engineering job. If it lists frameworks you will map and evidence you will collect, it is a governance job. If it lists design reviews, reference architectures, target states and standards, it is architecture.

There is also a structural fact about the role that candidates under-rate. Most security architects have no authority. You cannot block a release in most companies, and if you try, you get routed around: teams stop inviting you to the early meeting, which is the only meeting where you are useful. The architects who last build the paved road first and keep the veto for the two or three decisions a year that genuinely warrant it. Interviewers who have seen an architecture function fail will probe exactly this, and the honest answer about how you get adoption without power is the strongest thing you can say in a hiring-manager call.

• Questions that reveal which of the three jobs a posting really is: who approves a design today, and what happens when a team ignores the answer; how many designs went through review last quarter; does the architecture team own anything running in production; who writes the standards and who grants the exceptions; how big is the exception backlog; is there an architecture review board and does it have teeth.
• A typical week in the engineering-adjacent version: two or three design consultations with project teams, one design review producing a written verdict, work on one reference pattern or standard, one threat model, one escalation about an exception, and some time spent reading what teams are actually building versus what the diagram says.
• A typical week in the enterprise governance version: review board sessions, standards drafting and socialising, control mapping for an audit or a regulator, risk acceptance paperwork with named owners, briefings upward, and a lot of chasing teams who did not read the standard.
• What is not the job, despite the job adverts: running the security operations centre, owning vulnerability remediation, approving firewall changes as a day job, or being the person who says no at the end. An architecture function that becomes a ticket queue has already failed, and good interviewers ask how you would prevent that.

The step from senior engineer to architect: what actually changes, and what blocks the promotion

The searcher reading this is usually a strong senior or staff engineer who has been told, or has decided, that architect is next. The step is smaller than it looks in one way and much larger in another. Smaller, because the technical depth you already have is most of what the design round tests. Larger, because three things change at once: your output becomes written rather than built, you become accountable for designs implemented by people you do not control, and you start spending time on sequencing, money and politics rather than on the best available control.

Change one: you have to be right at a distance. An engineer who gets a design slightly wrong discovers it while building and fixes it quietly. An architect who gets it wrong hands the error to four teams and finds out in six months. That forces a different working style: explicit assumptions, written decisions, options rejected on the record, and a review date. The architecture decision record exists for exactly this reason, and the ability to write one is the single most transferable artefact from engineer to architect.

Change two: influence replaces authority. You are asking teams with their own roadmaps to absorb work that does not help them ship. The levers that work are a pattern that is less effort than the insecure alternative, being present before the design is finished, giving a clear yes rather than a vague maybe, and carrying someone else's constraint upward when it is legitimate. The lever that does not work is quoting a standard at a team that is late.

Change three: breadth taxes your depth, and it feels like getting worse at your job. You will be asked about identity, network, cloud, application, data, OT if the company has a plant, cryptography and key management, and the regulatory frame the company sits in. You cannot be strong in all of them. The architects who stay credible keep one area of genuine depth and maintain enough currency elsewhere to know which questions to ask and who to ask. The architects who lose credibility drop all hands-on work and become, in the phrase engineers actually use, a slide architect.

What blocks the promotion is rarely technical. The four recurring blockers: there is no written evidence of your judgement, because everything you decided lives in merged pull requests and Slack threads nobody can read; you cannot run a design review without taking the keyboard, which means you redesign instead of reviewing and teams stop coming; you cannot write a page, so your reasoning never survives contact with a decision maker; and you have never got a change adopted across teams you did not control, so nobody can tell whether you can do the only part of the job that is hard.

All four are fixable from where you are now, and the fixes double as interview material. Volunteer to write the design document and the decision records for the next project instead of only the code. Run a threat model for a team that is not yours and produce a written output with specific decisions, not a list of risks. Author one standard, publish the exception route with it, and track how many teams adopted it. Sit on or present to the architecture review board. Write the one-page brief your manager takes upward, then ask what happened to it. Lead the sequencing of one migration that spans several teams, including the part where you negotiate who goes last.

Expect the move to take twelve to twenty-four months of deliberate work, and expect it to be faster inside your current company than between companies, for the same reason it is faster in most senior roles: the internal panel has watched you make decisions, and an external panel only has your documents and 90 minutes. If you are going external, it is normal and sensible to target the smaller or more regulated employer first. A 400-person company with a real estate and one architect will give you the title and the scope a year before a company with a formal architecture ladder will.

• Evidence to build while still an engineer, in rough order of value: an architecture decision record set for a real project; a design review verdict you wrote for someone else's design; a standard you authored plus its adoption figure; a threat model with the design change it caused; a one-page risk brief that went to an executive; a cross-team migration plan with the sequencing and the rollback.
• Signals a hiring panel reads as architect-ready: you ask what the constraint is before proposing anything; you can describe a decision you later reversed and what the evidence was; you talk about who operates the thing you designed; you quantify something without being asked; you name the weakest part of your own design.
• Signals that read as not-yet: every answer is a product name; every design is greenfield; the answer to pushback is escalation; risks are listed rather than decided; nothing you describe has a cost or a time attached.
• Internal promotion mechanics that actually matter: being in the project kickoff rather than the pre-launch review, having your name on a document that circulated outside your team, and having an engineering leader outside security say in your review that your involvement saved them time.
• A harder truth about pay: the title step is sometimes lateral in money, particularly moving from a staff engineering band at a large technology employer into an architect title at an enterprise. Ask for the band before you fall in love with the title, and compare the ladder rather than the label.

Credentials: CISSP, SABSA, TOGAF, cloud, and what none of them buy you

Nothing licences this role. There is no board, no registration, no protected title, and no legal consequence to practising without a credential. What exists is a keyword filter, and on security architect postings that filter very often names CISSP. Treat it accordingly: it is the cost of being read at an enterprise, a bank, an insurer, a health system, a government department or a defence contractor, and it is close to irrelevant at a product company that interviews on design.

CISSP requires five years of cumulative paid experience across two or more of its eight domains, with one year waivable by an approved four-year degree or an approved credential, and an endorsement from an existing certified member. If you pass the exam without the experience you become an Associate of ISC2 and have a defined window to earn it. Maintenance is 120 CPE credits over a three-year cycle plus an annual maintenance fee, so it is a standing commitment rather than a one-off. For someone already working in security, two to four months of evening study is typical, and the thing that fails people is breadth: the exam asks about physical security, business continuity, software development lifecycle and law, and a deeply specialised engineer has gaps in half of it. Read the current exam outline on ISC2's own site rather than a secondhand summary, because the domain weightings are revised periodically.

The architecture-specific credentials are a shorter list than the marketing suggests. ISSAP is the CISSP architecture concentration, requires an active CISSP plus two years of paid experience in its own architecture domains, and is recognised in enterprise and defence settings while being invisible in startups. SABSA is the one you will see named in job adverts, particularly in the UK, Europe, Australia and across banking: the Foundation level is a short course plus exams, and the thing to actually learn from it is the method, which is driving a design from business attributes down to mechanisms so that every control traces to something the business said it wanted. Interviewers in SABSA shops ask you to trace a control to a requirement, and the method answers that question cleanly whether or not you hold the certificate.

TOGAF belongs on the list when the employer has a central enterprise architecture function, because it gives you the vocabulary that function uses and the credibility to sit at its table. Check which edition a training provider is teaching, because the standard has been restructured and employers quoting it rarely say which version they mean. GIAC GDSA, which maps to the SANS defensible security architecture material, is the most hands-on design credential available and also among the most expensive, so it is usually an employer-funded choice rather than a self-funded one. The Open Group Open CA deserves more attention than it gets: it is assessed by a peer board reading written packages describing your own projects, which means preparing for it produces exactly the artefacts an interview panel wants to see.

The credential decision that is most often wrong is stacking a second and third security certification instead of a cloud architect certification. If the estate you are being hired into is cloud-first, and most now are, then AWS Certified Solutions Architect Professional, Microsoft AZ-305 or Google Professional Cloud Architect does more for your credibility than another security acronym, because it signals you can design the platform rather than only critique it. The same logic applies to Kubernetes if the company runs it, and to IEC 62443 training if you are going anywhere near an industrial plant.

What no certification buys is the design round. Every panel has interviewed a candidate with a long certification line who could not sequence a rollout or name the trade they made. The defensible position in an interview is to hold the one credential that gets you read, say plainly that you hold it because it is the filter, and then spend your evidence on designs. If you are asked which certification you would do next, the strongest answer names the gap in your own practice rather than the next acronym in the series.

• Order of operations if you are starting from a senior engineering role at an enterprise: CISSP first because it unblocks the filter, then a cloud architect certification matching the target estate, then SABSA Foundation if your target market names it, then stop and build designs.
• Order of operations if you are targeting product companies and technology employers: skip ahead to the designs, and treat CISSP as optional until a recruiter tells you it is blocking you.
• Government and defence: the qualification requirement comes from the work role coding under DoD 8140 and is passed through in the contract rather than chosen by the employer, so ask which qualification this specific role requires and by when. A posting demanding an active clearance is genuinely closed until an employer sponsors you, and the investigation runs after the offer.
• Degrees: a bachelor's is a filter at some large employers and at most public-sector ones, and a master's is close to irrelevant at this level except in research-heavy or regulated settings. Nobody is hiring an architect on a degree, and nobody is rejecting one with ten years of design evidence for lacking one, except where a policy forces it.

Design evidence: the artefacts that get you shortlisted, and how to sanitise them

This is the part candidates skip, and it is the difference between a resume that gets read and a resume that gets an interview. For engineering roles the portfolio is a repository. For architecture the portfolio is writing, because writing is the medium of the job. A panel hiring an architect wants to see how you think when you are not in the room, and the only way to show that is a document.

You almost certainly cannot show the real ones. Design documents are employer property and frequently describe live weaknesses, so taking the file with you is both a breach and a red flag. The correct move is reconstruction: rewrite the artefact from memory with invented company names, invented numbers and generic technology, and say on the first line that it is a reconstruction of a design you led, with details changed. Interviewers see this often and read it as professionalism. A candidate who hands over a genuine internal document from a previous employer has told the panel exactly how they will treat their documents next.

Six artefacts do the work. First, an architecture decision record: one or two pages with the context, the decision, the options you rejected and why each was rejected, the consequences you accepted, the residual risk, and the date you would review it. Panels like this because it is compact and it is impossible to fake judgement in it. Second, a reference architecture for something ordinary, done well: remote access, a multi-account cloud landing zone, secrets and workload identity, a segmentation model, a logging and detection design with the monthly cost stated.

Third, a threat model that changed something. Not a list of threats. A model where you can point at a specific design change that happened because of the exercise, and ideally at a threat you decided to accept rather than mitigate, with the reasoning. STRIDE or an attack tree are both fine; the method matters less than whether the output ends in decisions. Fourth, a migration plan into a brownfield estate: the sequencing, which teams go first and why, what you audit before you enforce, how exceptions are granted with an owner and an expiry date, and the rollback.

Fifth, a design review verdict for somebody else's design: what you approved, what you made conditional, what you rejected, and what you deliberately let through because it was not worth the fight. This one is rare in portfolios and lands hard, because reviewing well is the skill that separates architects from senior engineers who redesign everything they are shown. Sixth, a one-page risk brief written for a non-technical executive audience, which is covered in its own section below and is the artefact most candidates do not have at all.

Two more things make the portfolio work. Keep every piece short, because length reads as inability to prioritise, and a panel that receives eight pages will read one. And have an opinionated written position on something in your specialism, published or not: why you would not deploy a particular pattern, how you would sequence a zero trust programme at a company with a mainframe, what you think the honest limits of microsegmentation are in a plant. A blog post containing a real design is worth more than a conference talk, and both are worth more than a certification you added last month.

• The architecture decision record template that holds up in an interview: context and constraint, the decision in one sentence, options considered with the reason each was rejected, consequences accepted, residual risk and who owns it, review date. If you cannot fill the rejected-options section, you did not make a decision, you had a preference.
• Reference architecture subjects that interview well because every employer has the problem: replacing a VPN concentrator for a mixed staff and contractor population with one legacy app that cannot do modern federation; a multi-account or multi-subscription cloud landing zone with guardrails; segmentation for a flat network containing devices that cannot be patched; secrets and workload identity for several hundred services; a tenancy model for a multi-tenant product with the proof of isolation.
• Sanitisation rules: invented organisation, invented scale figures that stay internally consistent, no real hostnames or IP ranges, no unremediated weakness that is still live, a stated line saying the document is a reconstruction, and nothing that identifies a client of a consultancy.
• Bring the artefacts to the interview rather than attaching them all to the application. One link or one page with the application, the rest on the table in the design round, where they turn an abstract conversation into a concrete one.
• If genuinely everything you have done is classified or under tight NDA, write a fresh design for a fictional company instead and say so. 'It is all under NDA' with nothing offered is read as having nothing, and it is a common reason a strong cleared candidate loses to a weaker uncleared one.

The resume a head of security architecture actually reads

Two pages. Three is tolerated at this level if the second and third are dense with designs rather than with duties, and a six-page document listing every tool you have touched since 2014 reads as someone who cannot prioritise, which is the central skill of the job you are applying for.

The reader is usually the head of security architecture, a principal architect, or a CISO at a smaller company, and they read in a fixed order. Scope first: how big was the estate, how many engineers, how many users, regulated or not, cloud or hybrid or on-premise. Second, whether you decided things or supported decisions, which is visible in the verbs. Third, whether anything you designed actually shipped. A resume that passes those three gets read properly; one that fails them gets 20 seconds.

The structural change from an engineering resume is to add an architecture or selected designs section near the top, above the chronological history. Three to six entries, one or two lines each, every one shaped the same way: the constraint, the decision, what you traded away, and the outcome. As an illustration of the format: 'Replaced a hub-and-spoke VPN for 4,000 staff and 600 contractors with device-attested access; kept the one legacy application on a brokered path with compensating monitoring rather than delaying the programme a year; cut standing network access from the whole estate to a named 14 percent of it in nine months.' That is a design, a trade and a result in one sentence, and it is the shape that gets interviews. Use your own real figures, and if you do not have them, state the movement in words instead.

Verb discipline matters more here than anywhere else in security hiring. 'Designed and got adopted' beats 'designed'. 'Decided X over Y because Z' beats 'evaluated X and Y'. 'Wrote the standard and closed two thirds of the open exceptions' beats 'owned security standards'. Every passive construction hides whether you actually made the call, and panels have learned to read passive voice as somebody else's decision.

Numbers that carry weight at this level are scope and movement, not vulnerability counts: estate size, number of teams or business units, users, spend you influenced or saved, latency or availability budget you designed within, proportion of the estate migrated and over what period, number of designs reviewed, exceptions closed, standards adopted and by how many teams. If you cannot support a number, describe the shape instead. An invented precision is worse than an honest 'most of the estate' because one follow-up question destroys it.

What gets ignored or actively costs you: a logo wall of security products, because the panel assumes you have used the common ones; a certification list in the header, which reads as insecurity, so put them in one line at the end; 'excellent communication skills' on a resume being read precisely to assess communication; CVE and finding counts, which are an engineer's metric; 'thought leadership'; and any sentence containing the words strategic enabler. Publications and talks are mild positives, and a written design is a strong one, so link to it rather than listing the venue.

Two final mechanics. The ATS filter still exists at enterprises, so the frameworks and domains you have genuinely worked in must appear as words somewhere: zero trust, identity and access management, PKI and key management, segmentation, threat modelling, NIST Cybersecurity Framework, ISO 27001, SABSA, cloud platform names. And at architect level the short cover note earns its place, which it rarely does for engineers: three or four sentences saying what you think the hardest unsolved problem in their environment is, based on the posting and the public record. Hiring managers buying judgement respond to a candidate who has already started using some.

• Title line that works: the title plus the scope in brackets. 'Security Architect (hybrid estate, 12,000 users, PCI DSS and SOC 2 in scope, 40 engineering teams)' tells the reader in one line what three bullet points would not.
• A good architecture entry answers four questions in under 30 words: what was the constraint, what did you decide, what did you give up, what happened. If any of the four is missing the entry is a duty, not a design.
• Keep a hands-on line alive. One or two concrete items such as the infrastructure-as-code you still write, the policy-as-code rules you authored, or the lab you run. It stops the panel's biggest worry at this level, which is hiring someone who has not touched a system in five years.
• Tailor to which of the three jobs the posting is. Engineering-adjacent: lead with designs that shipped and the code you still write. Enterprise governance: lead with standards adoption, review board work and regulatory scope. Vendor presales: lead with customer-facing design work and the deals it helped close.
• LinkedIn is a sourcing channel for this role in a way it is not for junior roles. Recruiters search title plus CISSP plus a framework plus a platform, so the words have to be in the profile, and the headline should say which specialism you are rather than 'cybersecurity professional'.

How hiring runs, and what the design round really tests

There is no licensing body, no standard exam and no union in this process. What there is, at an employer with an in-house recruiting function, is four to seven conversations over four to eight weeks, slower than engineer hiring because an architect hire needs sign-off from people outside security. Consultancies run a compressed version with a client-facing presentation. Vendors run a presales version with a demo and an objection-handling exercise. Not every employer runs every stage below, and a smaller company may do the whole thing in three conversations.

Stage one, recruiter screen, 20 to 30 minutes, filtering only: years, location, work authorisation, clearance if relevant, salary expectation, notice. Use it to find out which of the three jobs it is, using the questions in the first section, and ask for the band. Stage two, hiring manager, 45 to 60 minutes, and this is where most candidates are weakest. They want a narrative: what you own now, one design you took from a blank page into production, one decision you got wrong and how you found out, and how you handle an engineering team that does not want your change. Have three stories at the level of specific systems and specific pushback, not at the level of 'stakeholder alignment'.

Stage three is the live design round, 60 to 90 minutes on a whiteboard or a shared document, and it decides the offer. The brief is deliberately underspecified. The interviewer is not waiting for a product name, and the single most common failure is starting to draw within the first minute. What they are measuring is whether you establish requirements and constraints before designing, whether you state assumptions out loud, whether you reason about trust boundaries and blast radius rather than about features, whether your design can be rolled into an estate that already exists, whether you know what it costs, and whether you can say where it is weak.

The shape of a strong answer is consistent across employers. Narrow the problem first: who are the users and how many, what is the data and its classification, which regulatory regime applies, what exists today, who operates it, what is the appetite for breaking things, what is the budget and the deadline. Then design identity before network, because in almost every modern estate the identity layer is the real perimeter. Then say, for each control you propose, how you would know it had failed, because a control with no telemetry is an assumption. Then give the sequencing: what you do in the first quarter, what in the first year, what you audit before you enforce, and how exceptions are granted with a named owner and an expiry date. Then, unprompted, name the two weakest points in your own design and what you would do about them with another quarter. That last move is the clearest senior signal available in 90 minutes.

Stage four is usually a design review or a written exercise. The review version hands you somebody else's design, often one with a deliberate flaw and several merely imperfect choices, and watches whether you can distinguish the three things you must fix from the eight you should let go. Architects who reject everything are as unhireable as architects who approve everything. The written version is a short take-home, two to four hours, producing an architecture decision record or a design review memo. An employer asking for more than four hours of unpaid work is telling you something about how they will treat your time later.

Stage five is the cross-functional round with an engineering, platform or product leader who does not report to security. They are deciding whether working with you would be miserable, and the question underneath every question is whether you accept that their delivery dates and their uptime are also real requirements. Answer in those terms: migration paths, audit before enforce, exceptions with owners and expiry dates, who you would consult before enabling a deny, and a case where you accepted a weaker control because the stronger one would not have been adopted.

Stage six, at enterprises and in regulated industries, is an executive communication round, covered in the next section. Stage seven where it exists is the CISO or values round. In regulated industries you may also meet internal audit or operational risk, who will ask how you evidence a control and what you do when the control works but the evidence does not exist. For cleared work add the investigation after the offer, measured in months.

Two process notes worth knowing. First, references are taken more seriously at this level and are frequently backchannel, so assume the panel will talk to someone who watched you make decisions. Second, the counter-offer dynamic is different: because internal promotion is the most common path into this role, your current employer often can match on title, and if the architect title is what you actually want, asking internally first costs you nothing but a conversation.

• Design prompts that recur now: secure a new customer-facing platform handling card data and personal data across two regions; integrate an acquired company with its own directory and its own cloud accounts over 12 months; replace VPN remote access for staff and contractors with one legacy application that cannot federate; segment a flat plant network containing unpatchable operator stations; design the identity architecture for a company with two identity providers, 200 SaaS applications and a mainframe; design secrets and workload identity for a thousand services; design logging and detection to a stated monthly budget; design and prove tenant isolation for a multi-tenant product; add an AI assistant over an internal document store without leaking what it indexed.
• What the interviewer is scoring, in the order they care: requirements before design, explicit assumptions, trust boundaries and blast radius, a sequenced path from today's estate, cost and operability, detection for every control, residual risk stated without being asked, and self-criticism of your own design.
• Answers that fail the round: product-name bingo; a greenfield design for a brownfield question; no questions asked at the start; refusing to commit to a decision because 'it depends' without saying on what; a control nobody could operate; ignoring the money; 'we would implement zero trust' with no sequencing; and treating the legacy system as somebody else's problem.
• Questions that recur in the detail and separate architects from engineers: who can decrypt versus who can use a key; what actually enforces a boundary on a managed service; how you give a deployment pipeline rights without giving it administrator; how you stop a stolen workload credential being used from outside your network; what breaks when you turn on enforcement; what you would do if the project is already two weeks from launch.
• Questions you should ask them: what is the last design that went badly and what changed afterwards; how many exceptions are open and who owns the oldest one; who can overrule you and how often do they; what proportion of projects reach you before the design is fixed; what would success look like at six months; what is the architecture function's reputation with engineering right now.
• If you are asked to present a past design to a panel, present the decision rather than the diagram. Five minutes on the constraint and the trade, two minutes on the picture, and a clear statement of what you would do differently now.

Executive communication: the round that eliminates strong engineers

Most security architect job descriptions contain a line about communicating with senior stakeholders, and most candidates read past it. It is tested, it is tested specifically, and it is where strong engineers lose offers. The reason is structural: an architect's designs cost money and slow delivery, so somebody with budget authority has to say yes, and the architect is the person who has to make that possible in ten minutes to an audience that cannot evaluate the technology and is personally accountable for the outcome.

Be clear about how far up you actually go, because the job adverts blur it. Most security architects do not present to a board. What usually happens is that your paper, your numbers and your option set go into the CISO's quarterly pack, and you are in the room occasionally for the technical question or to present a specific programme. The audience you write for week to week is an executive committee, a technology leadership team, a risk committee or a steering group. That makes the skill the same one either way, and it is worth preparing for the harder version: a board audit or risk committee meets quarterly, has a packed agenda, received your paper two days ago at best, is composed of people who are accountable for the company's risk posture, and is there to make decisions rather than to be educated. They want to know what could go wrong, how bad it would be in money and in regulatory and reputational terms, how likely it is and on what basis you claim that, what the options are with price and time attached, which one you recommend, and what they have to do.

The format that works is one page. The decision you are asking for, in the first sentence. The exposure in business terms: what stops working, what gets disclosed, who notices first, what it costs to recover, and what a regulator or a major customer would do. The likelihood in plain words with the basis stated, which may be an incident you had, an industry pattern, an audit finding or a tested control failure, and which must not be a number you invented. Two or three options, each with cost, elapsed time, what it does not fix, and the residual risk remaining after it. Your recommendation, named as a recommendation. What you need: money, a mandate, or a risk accepted in writing by a named owner with a review date. And the date you will come back.

The elimination behaviours are consistent. Starting with technology rather than with consequence. Presenting risk without a recommendation, which reads as refusing to do your job. Saying 'high risk' with nothing behind it. Forty slides. Headline-breach fear as an argument, which experienced directors have been immunised against. Refusing to give any number because the data is imperfect, when a range with stated assumptions is exactly what the room wants. Using 'we are not compliant' as the entire case, which invites the cheapest possible compliance fix rather than the right design. And treating the room as an obstacle rather than as the people who can clear your path.

Expect the interview to test this directly rather than by reputation. The common forms: explain multi-factor bypass, or a supply chain compromise, to a non-technical director in two minutes; you have five minutes with the CFO and you need a specific sum, go; the board asks whether the company would survive a ransomware event, answer; here is a scenario, write the one-page brief. A favourite variant puts a technical person in the room who disagrees with you and watches whether you can hold the position without being rude or abandoning it under pressure. Both failure modes are disqualifying, and panels specifically watch for the candidate who folds to seniority, because an architect who folds is worth nothing in a design review.

On quantification, say the narrow true thing. Factor Analysis of Information Risk, usually called FAIR, is worth knowing because interviewers ask about it and because the discipline of decomposing a risk into frequency and magnitude, then stating ranges and assumptions, makes you better in the room. It is also oversold as precision: the inputs are estimates, and a confident single-figure annualised loss number invites a correctly sceptical director to take the whole brief less seriously. Ranges with the assumptions visible, plus a statement of what would change your estimate, is both more honest and more persuasive. Many boards still work in red, amber and green heat maps, which are analytically weak, so the practical skill is carrying quantified reasoning into a qualitative format without lecturing the room about why its format is bad.

Two artefacts are worth having written before you interview, because they double as portfolio pieces. A one-page risk brief in the structure above, for a real scenario with the names changed. And a risk acceptance record: the thing you write when the business declines your recommendation, naming the accepted risk, the accountable owner, the compensating measures, the expiry date and the review trigger. Being able to produce the second one calmly is a senior signal, because it shows you understand that the business is allowed to say no and that your job is to make the decision informed rather than to win every argument.

• The one-page structure, in order: the decision requested; what happens if nothing changes, in business consequence; likelihood with its basis; two or three options with cost, time, what remains unfixed and residual risk; your recommendation; what you need from them; the date you return. Everything technical goes in an appendix nobody will read, which is fine, because its purpose is to exist.
• Translation examples worth rehearsing: standing administrative access becomes 'any one of 60 laptops can be used to stop the plant, and we would not know which for two days'; an unsegmented network becomes 'a compromise in the call centre reaches the payments environment in one step'; missing recovery testing becomes 'we have backups and we have never proved we can restore the ordering system inside a week'.
• Phrases to retire in front of an executive audience: attack surface, lateral movement, posture, uplift, maturity journey, defence in depth, and anything with the word synergy. Say what stops working and who finds out.
• Say the limits out loud. 'This reduces the chance of the ordering system being down for more than a day. It does nothing about a dishonest insider, and that is a separate paper in the autumn.' Naming what your proposal does not fix is the fastest way to be believed about what it does.
• The under-practised skill is the two-minute verbal version, because meetings run late and the paper gets cut. Have the whole argument in five sentences, and have the ask in one.

Specialisms, titles, pay and the shape of the 2026-27 market

Security architect is not one labour market, it is several, and they hire on different evidence. Enterprise and infrastructure architecture remains the largest pool and hires on breadth, standards work and brownfield sequencing. Cloud security architecture is the fastest-moving and increasingly the default, hiring on platform depth and on landing zone and identity design. Application or product security architecture hires on software design judgement, threat modelling and the ability to argue with engineers in their own terms. Identity architecture is a specialism in its own right and is persistently short of credible people, because the work spans directory services, federation, privileged access, entitlement models and the politics of joiners, movers and leavers. Data security architecture is growing because of where analytics and AI workloads put data.

Network security architecture is the one shrinking relative to the others, as enforcement moves from appliances into identity, service meshes and cloud policy layers; network architects who have made that move are in demand and the ones who have not are competing for fewer jobs. Operational technology and industrial control systems architecture is genuinely scarce: it needs IEC 62443 fluency, patience with equipment that cannot be patched or rebooted, and a willingness to be on a plant floor, and employers in energy, water, manufacturing and transport struggle to fill it. Payments, healthcare and defence each carry their own regime, their own evidence culture and their own pay dynamics.

The 2026-27 market has a specific shape, and it is not the 2021 market. Standalone architect headcount is harder to get signed off than it was in the hiring boom, more roles are filled by internal promotion, and you will see more postings that fold architecture into a principal engineer or engineering leadership title rather than funding a separate architecture function. Against that, demand holds up in regulated industries, in consultancies and managed service providers who sell architecture as a service, and anywhere a company is being asked by customers or regulators to evidence how its systems are designed rather than how they are monitored. The clearest new line item in postings is an AI security expectation bolted onto an otherwise conventional architect role, which is covered in the next section.

Titles are unreliable and you should read scope rather than label. Security architect, senior security architect, principal security architect, lead security architect, enterprise security architect, cyber security architect and security solutions architect can all describe the same work, and the same words describe wildly different seniority between a 300-person company and a bank. Security solutions architect at a vendor is usually presales. Chief architect or head of security architecture is a people-leading role. The useful questions are how many architects exist, who they report to, what they are allowed to decide, and whether anyone has veto.

On pay, do not trust a single quoted band, including one from a salary site that does not say how it was collected. There is no BLS occupation for security architect; the nearest official series are Information Security Analysts, SOC 15-1212, and Computer Network Architects, SOC 15-1241, in the BLS Occupational Employment and Wage Statistics, and both understate architect pay at a large employer because they blend in more junior work. Build your own picture: posted ranges in pay-transparency states, levels.fyi for levelled technology employers, published public-sector and university schedules as a floor, union or civil service bands where they apply, and the recruiter's own band asked for on the first call. Then hold a range rather than a number, and ask theirs first.

Two market realities worth planning around. Consultancy is a faster route to the title and to volume of design experience, at the cost of depth and of travel; many architects do three years in consulting precisely to collect designs and then move in-house. And the career path beyond architect forks: principal or distinguished architect as a deepening individual contributor track, head of architecture as a people-leading track, and CISO as a different job again that is mostly risk, budget and board work rather than design. Knowing which fork you want changes what you should be collecting now, because the evidence for principal architect is designs and the evidence for CISO is accountability and money.

• Specialism demand, honestly stated: cloud and identity strongest and most transferable; application and product security strong at software companies; OT and ICS scarce and well paid but geographically constrained; data security growing on the back of analytics and AI workloads; appliance-centric network architecture weakest unless modernised.
• Regimes that unlock whole segments if you actually know them: PCI DSS for payments, including the customised approach route; HIPAA Security Rule for US healthcare; FedRAMP and CMMC for US government and defence suppliers; IEC 62443 for industrial; DORA and sector regulators for European financial services; ISO/IEC 27001 Annex A as restructured in the 2022 revision, used almost everywhere as a common language.
• Framework fluency employers assume rather than ask about: NIST Cybersecurity Framework 2.0 and its Govern function, NIST SP 800-53 control families, NIST SP 800-207 for zero trust architecture, CIS benchmarks, MITRE ATT&CK for threat-informed design, OWASP ASVS for application requirements, and STRIDE or attack trees for threat modelling.
• Negotiation points that are often more winnable than base pay at this level: scope and reporting line, whether you own anything in production, training and conference budget, the right to keep a lab, and a written statement of what you are allowed to decide. The last one is worth more than it sounds, because an architect without decision rights is an advisor with a deadline.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

• Security architect
• Security architecture
• Enterprise security architecture
• Cyber security architect
• Reference architecture
• Architecture decision record (ADR)
• Design review
• Architecture review board (ARB)
• Target state architecture
• Threat modelling
• STRIDE
• Attack tree
• Zero trust architecture
• NIST SP 800-207
• NIST Cybersecurity Framework 2.0
• NIST SP 800-53
• ISO/IEC 27001
• SOC 2
• PCI DSS
• HIPAA Security Rule
• FedRAMP
• CMMC
• DORA
• IEC 62443
• CIS Benchmarks
• MITRE ATT&CK
• OWASP ASVS
• Identity and access management (IAM)
• Federation
• SAML
• OIDC
• Privileged access management (PAM)
• Entitlement management
• Microsoft Entra ID
• Okta
• Active Directory
• Public key infrastructure (PKI)
• Key management
• Encryption at rest and in transit
• Network segmentation
• Microsegmentation
• Secure remote access
• SASE
• Cloud security architecture
• AWS
• Microsoft Azure
• Google Cloud
• Landing zone
• Multi-account architecture
• Kubernetes security
• Infrastructure as code
• Terraform
• Policy as code
• Secrets management
• Workload identity
• Non-human identity
• Data security architecture
• Data classification
• Logging and detection design
• Security standards and exceptions
• Risk acceptance
• Residual risk
• FAIR risk quantification
• Executive reporting
• Board reporting
• CISSP
• ISSAP
• SABSA
• TOGAF
• GIAC GDSA
• AWS Certified Solutions Architect Professional
• Microsoft AZ-305
• Google Professional Cloud Architect
• DoD 8140
• Security clearance
• OT security architecture
• AI security architecture
• Prompt injection
• Retrieval augmented generation (RAG)
• Agent security
• Model Context Protocol (MCP)
• NIST AI Risk Management Framework
• ISO/IEC 42001
• OWASP Top 10 for LLM Applications
• MITRE ATLAS

Mistakes that cost people this job

Questions people ask