Skip to main content
POST ATLAS

Sample report

Senior Security Architect

A live Hiring Reality Report rendered from a realistic brief. The shape you see here is the five-section product. Call. Reasoning. Forecast. Recommendations. Support. Everything below the header is generated by the same engine that will run on paid reports.

Back to recruiters

Hiring Reality ReportSenior Security Architect
Section 01 · The call
One diagnosis on the brief as written

Section 01

The call

Hiring Reality

The seat covers cloud, application, identity and data architecture in one head, and no candidate carries all four at the depth the brief asks for.

The brief asks for production-grade depth across four architecture domains that are usually owned by different people inside a mature function. The shortlist will tend toward consultancy backgrounds, where breadth has been accumulated through client exposure rather than through ownership.

Role

Senior Security Architect

£110,000 to £125,000

Location

London

2 days per week in office

The shift this report makes

Not the candidates

The brief is the thing being judged.

Section 02 · Why this call
The reasoning behind the diagnosis

Section 02

Why POST made this call

Cloud, application, identity and data architecture are typically owned by different people inside a mature security architecture function. Asking for deep production experience in all four within one seat reduces the available pool to candidates who have touched everything without owning anything, which is most commonly a consultancy background. Domain specialists with real production scars in any one domain tend to self-select out at the requirements section because they know the working session will catch the gaps in the domains they have not owned.

What in the brief led us to this conclusion

  • Exec reporting, board reporting, or executive stakeholder management
  • Strategy ownership bundled into an architect seat
  • Team building and management bundled with architecture
Section 03 · The forecast
If the brief goes to market as written

Section 03

What usually happens if nothing changes

In the market

  • The shortlist tends to be the same three consultancy alumni who have touched everything and owned nothing.

  • Specialists in each domain self-select out before they apply, because they recognise the gap between the brief and their working experience.

  • Internal feedback after interviews is usually consistent: candidates look impressive on paper and weaker in the working session.

  • The role re-opens twice before someone agrees that the scope of the brief is the underlying problem.

Why candidates disengage

Domain specialists know they will be carried by three areas they do not have depth in, and the imposter cost is not worth the compensation on offer.

Generalists know the seat will pull them away from the one area they care about most.

Both groups also know the working session is likely to surface the gaps that the CV review missed.

What you're likely to see in your pipeline

  • CVs that list every domain with no operational specifics in any of them.
  • Working sessions that go well until the second domain comes up.
  • Candidates asking, often in the first interview, who owns the domains the seat does not cover.
Section 04 · What should change
Edits you can put to the hiring manager

Section 04

What should change

Changes to the brief
  • Pick the load-bearing domain and hire to that depth. Treat the other domains as collaboration scope.
  • Name the owners of the other domains inside the brief so candidates know where the boundaries sit.
  • Drop one domain entirely from the brief. Two domains can usually be carried at depth by one architect, three is generally not achievable, and four leads to the consultancy-style breadth the brief is currently filtering for.

Edits that would change this call

  • Name the primary architecture domain in the brief and treat the others as collaboration scope.

  • List the named owners of the domains this seat will not own.

  • Cut at least one domain entirely from the brief.

What to test for in early screens

  • Ask for a recent design decision in the candidate's weakest declared domain.
  • Probe the seam between two domains, rather than depth in one.
  • Listen for who the candidate has said no to in previous seats, not only what they have said yes to.
What a workable version of this brief looks like

The brief picks one of three things to be: senior IC architect, lead architect with delivery responsibility, or head of security with an architect title. It defines the reporting line, the team it owns or doesn't own, and the budget authority. The salary band reflects that choice.

Section 05 · Supporting context
Reference material for the hiring-manager conversation

Section 05

Supporting context

What this seat really is

The shape of the work the hire actually carries.

  • The work this seat mostly is

    Generalist principal who can pattern-match credibly across domains

  • The work this seat also carries

    Deep specialist in one domain with working knowledge of the others

  • What this seat isn't, despite the title

    Four senior architects compressed into a single salary band

Where the strongest candidates actually sit

Backgrounds that tend to produce people who can do this work

  • Principal security engineer with cross-team design experience

    Already does the architecture work informally, usually inside the function that owns the engineering decisions. The architect title formalises an existing position rather than asking the seat to earn one from outside.

  • Cloud or platform staff engineer with strong security instincts

    Sits inside the engineering function whose decisions the architect is meant to influence. Brings the credibility that lets standards land rather than being routed around.

  • Consulting security architect from a delivery-heavy practice

    Has lived through influencing engineering decisions without formal authority over the teams making them. Tends to be sharper than expected on the political shape of the seat.

  • Domain architect (cloud, identity or data) ready to broaden

    Has owned the depth in one architecture domain and is ready to take pattern responsibility across more. Brings real production scars rather than framework fluency.

Built on POST Atlas's practitioner-authored assessment framework.

Section 06 · Rewritten brief
A version of this brief that filters for the work the seat actually does

Section 06

Forwardable to the hiring manager

Senior Security Architect

Cloud, application, identity and data architecture are typically owned by different people inside a mature security architecture function. Asking for deep production experience in all four within one seat reduces the available pool to candidates who have touched everything without owning anything, which is most commonly a consultancy background. Domain specialists with real production scars in any one domain tend to self-select out at the requirements section because they know the working session will catch the gaps in the domains they have not owned. The band is £110,000 to £125,000, 2 days per week in office.

Who this is for

  • Principal security engineer with cross-team design experience. Already does the architecture work informally, usually inside the function that owns the engineering decisions. The architect title formalises an existing position rather than asking the seat to earn one from outside.
  • Cloud or platform staff engineer with strong security instincts. Sits inside the engineering function whose decisions the architect is meant to influence. Brings the credibility that lets standards land rather than being routed around.
  • Consulting security architect from a delivery-heavy practice. Has lived through influencing engineering decisions without formal authority over the teams making them. Tends to be sharper than expected on the political shape of the seat.
  • Closest profile match: Generalist principal who can pattern-match credibly across domains.

Who this is not for

  • Senior individual contributors who have never produced a strategy document an executive committee actually read.
  • Head-of candidates currently running a team who would treat this seat as a step down in authority.
  • Mid-level architects who can carry the design half but have never owned executive stakeholder management.

What changes vs the original brief

  • · Name the primary architecture domain in the brief and treat the others as collaboration scope.
  • · List the named owners of the domains this seat will not own.
  • · Cut at least one domain entirely from the brief.