They lose time because the engagement was never made ready.

That sounds wrong until you have managed testing at volume.

The test itself is often the cleanest part of the process. The tester has the scope, the access, the rules of engagement and the test window. They know what they are there to do. The real friction usually sits in the weeks before that point, where scope is agreed, environments are confirmed, access is provisioned, credentials are created and the client works out who owns which blocker.

I manage penetration testing programmes for a consultancy. In one managed service programme, we run 30+ tests a quarter, alongside ad hoc engagements for other clients. At that volume, pre-engagement friction is not admin. It is one of the biggest threats to tester utilisation, delivery confidence and the quality of the work.

A stalled test does not just affect one date in the diary. It creates a gap in tester allocation, forces the programme manager to pull another test forward, puts pressure on reporting timelines and leaves both sides trying to recover from something that should have been visible earlier.

It can also weaken the assurance itself.

When a test starts late, starts half-ready or starts against the wrong conditions, the tester has less time to follow attack paths properly. Coverage narrows. Findings become caveated. The report ends up explaining limitations that should have been handled before the work began.

That is why I do not see pre-engagement as a testing problem.

It is a delivery problem.

Where the Time Goes

The pattern is familiar.

A test is booked. The client agrees a date. The tester is allocated. Everyone assumes the difficult part is done because the work is now in the calendar.

Then the basics start to slip.

VPN access is incomplete. Test accounts are missing. The environment is unstable. Scope is still being discussed two days before the test window opens. Nobody is fully sure whether the tester needs admin access, user access, API credentials or a specific application role. The escalation contact cannot make decisions. The delivery team thinks security owns the action. Security thinks the application team owns it.

The tester is blocked before they have started.

At small scale, that is frustrating. At programme scale, it becomes expensive very quickly.

Good testers are scheduled tightly. Most consultancies do not have skilled people sitting idle waiting for an environment to become ready. When pre-engagement slips, the impact lands on utilisation, reporting timelines, client confidence and the quality of the assurance itself.

The work does not fail because the tester lacked skill.

It fails because the engagement was not made ready.

What Actually Works

A few things have made a real difference in practice.

1. Do useful preparation before the first call

The best pre-engagement process starts before the kickoff.

Where a client has mature request, asset or service management information available, use it. Where they do not, ask for enough context up front so the first call does not become a cold discovery session.

You do not need everything before the call, but you do need enough to avoid wasting tester time.

The aim is simple: arrive with a working view of the system, likely scope, access needs, environment constraints, known stakeholders and likely blockers before technical resource is committed.

That changes the conversation.

Instead of asking, “What do you want tested?”, you can ask, “Is this the right interpretation of the system, the exposure and the likely test boundaries?”

That is a better use of everyone’s time.

2. Let the pentester lead scoping where possible

Scoping should not be treated as a purely administrative exercise.

If there is enough information available, I prefer the pentester to join the kickoff and lead the technical scoping conversation. Not two meetings. Not a project call followed by a separate technical call a week later. One proper session where the right person asks the right questions.

The pentester should prepare or heavily shape the scoping document.

That gives them early ownership. It also reduces the risk of scope being defined by someone who understands the delivery process but not the technical surface.

A programme manager can coordinate the engagement, protect the timeline and make sure actions move. But the tester understands what access, coverage and constraints will affect the quality of the work.

Use that knowledge early.

3. Put named owners on both sides

Pre-engagement fails when actions are left floating between teams.

A single engagement owner on the client side makes a significant difference. That person does not need to complete every action themselves, but they do need to own coordination, chase internal teams and make decisions when blockers appear.

On the consultancy side, access, credentials, rules of engagement, escalation contacts, environment readiness and reporting requirements should be tracked as real delivery actions.

Not comments in a call.

Not assumptions.

Tasks with owners.

If nobody owns the action, nobody should be surprised when it does not happen.

4. Keep forward visibility across the pipeline

At programme volume, you need to know what is ready, what is at risk and what can move.

A good testing programme should have forward visibility across upcoming engagements, tester allocation, known blockers, client readiness and dependency dates. Without that view, every delay becomes a surprise.

This does not need to be over-engineered. A simple readiness tracker or pipeline board can be enough if it shows the right things: scope status, access status, environment status, client owner, tester allocation, go/no-go date and blockers.

If a test is not ready, you need options.

Can another test be pulled forward?

Can the tester switch to reporting?

Can a different activity fill the gap?

Can the client recover the blocker before the go/no-go point?

Without pipeline visibility, the answer is usually discovered too late.

That is when client delay turns into dead tester time.

5. Use a go/no-go gate with real meaning

A test should not drift into the test window half-ready.

There should be a clear go/no-go point before the start date. By that point, the key questions need answering.

Is scope agreed?

Are rules of engagement signed off?

Is access working?

Are test accounts created?

Is the environment stable enough?

Are escalation contacts confirmed?

Does the tester have what they need to begin?

For managed service clients, there may be some flex. You can absorb delay, re-plan, escalate and recover where possible. But it still needs to be visible.

For ad hoc clients, cancellation terms and readiness thresholds need to be clear. If a client is not ready inside the agreed window, there should be a commercial consequence. Without that lever, readiness becomes optional.

A go/no-go gate only works if “no” is a real answer.

The Environment Problem

One of the hardest conversations is about test environments.

Staging is never production. Everyone knows that. But the gap between the environment described in planning and the environment found by the tester is often wider than either side expects.

The client may believe staging mirrors production closely enough. The tester may find missing roles, different data, disabled integrations, old code, broken workflows or access paths that do not reflect how the live system works.

That does not make the test useless, but it changes what the results mean.

The expectation needs setting early.

Provide the environment that most closely mirrors production. Be honest about known differences. Confirm what is in scope and what cannot be validated. Record the agreed environment position in the report so nobody later pretends the test covered something it could not reasonably assess.

I also like a light access check before the test window starts.

VPN. Credentials. Application reachability. Role access. Basic workflow confirmation.

Five minutes of validation can save days of wasted test time.

Blanket Code Freezes Usually Create the Wrong Fight

Asking for a blanket code freeze often creates friction with delivery teams for limited gain.

In modern delivery environments, releases still move. Defects still get fixed. The business does not stop because a penetration test is booked.

A more useful conversation is about stability and change visibility.

What version are we testing?

Is the environment stable enough to give the tester a fair view?

Are planned deployments expected during the test window?

Who communicates changes if they happen?

What needs recording in the final report?

That is usually cleaner and more realistic than demanding a perfect freeze nobody can maintain.

We are not trying to stop delivery entirely. We are trying to create a fair testing baseline, preserve assurance quality and document the conditions properly.

Stable scope, stable access and clear visibility of change usually deliver more value than a blanket freeze.

The First Test Is the Hard One

Pre-engagement gets easier when testing moves from annual one-off activity to a recurring programme.

The first test is often painful.

The client learns what information is needed. Internal teams learn how long access takes. Application owners learn that vague scope creates delay. Security learns who can make decisions. The consultancy learns how the client moves.

By the fifth test, the process should feel much more routine.

Access provisioning becomes familiar. Scoping becomes incremental. The client owner knows what is coming. The tester gets cleaner inputs. Reporting improves because the engagement started properly.

That is one of the real benefits of a managed or continuous testing programme. It is not only more testing. It is a better operating rhythm around the testing.

Practical Model

For high-volume penetration testing, I think about readiness in six parts.

1. Engagement setup

What is being tested, why now and who owns the engagement?

2. Scope clarity

What systems, roles, interfaces, APIs, environments and exclusions are in scope?

3. Access readiness

What credentials, VPN access, allowlisting, accounts, test data and permissions are needed?

4. Environment confidence

How close is the test environment to production, what is different and what could affect the findings?

5. Delivery control

Who owns actions, how are blockers escalated and when is the go/no-go decision made?

6. Reporting context

What assumptions, limitations, environment notes and change events need reflecting in the final report?

That model is simple, but it forces the right conversations before tester time is wasted.

Pre-Engagement Readiness Checklist

Before the test window opens, I want clear answers to these questions:

• Has the business objective for the test been confirmed?

• Has the technical scope been agreed by someone who understands the system?

• Has the tester reviewed or helped shape the scope?

• Are rules of engagement agreed?

• Is there a named client owner?

• Are escalation contacts confirmed?

• Are VPN, allowlisting or network access requirements complete?

• Are test accounts created with the right roles?

• Has basic access been validated before the start date?

• Is the test environment stable enough?

• Are known differences from production recorded?

• Are planned changes during the test window understood?

• Is the go/no-go decision point agreed?

• Are cancellation or readiness consequences clear?

• Does the final report need to state any limitations or assumptions?

If those questions feel heavy, that is usually a sign the organisation has been relying on goodwill and heroics instead of process.

Consultant Delivery Note

Do not treat pre-engagement as admin.

It is part of the security service.

If the client cannot provide access, stable scope, test accounts, escalation routes and environment clarity, the quality of the test will suffer before the tester opens a tool.

A good consultant makes that visible early, without drama. Clear prerequisites, named owners and a proper go/no-go point protect the client, the tester and the quality of the work.

This is also where programme management earns its keep. Not by adding ceremony, but by removing avoidable friction so skilled people can do skilled work.

Bottom Line

Pre-engagement overhead is not a testing problem.

It is a delivery problem.

The fix is structural: clear ownership, useful preparation, forward visibility, practical readiness tracking and commercial consequences where needed.

If your testing programme is losing time before testers even start, the problem is probably not your testers. It is probably the delivery wrapper around the work.

Fix that first.

A good pentest starts before the test window opens. Everyone involved needs to carry their weight before the tester is expected to carry the risk.

I’ll turn this into a simple pre-engagement readiness checklist for consultants running testing at volume. The aim is not more admin. It is fewer wasted test windows, cleaner scope and better assurance.

Most land on the same two questions:

How do we govern AI properly? How do we prove it’s actually secure?

ISO 42001 answers the first. AIUC-1 answers the second.

Treat them as competing and you slow yourself down. Treat them as a pair and you get something that holds up under pressure.

Where Most Organisations Are Right Now

ISO 42001 gave the market something it was missing.

A way to structure AI governance properly. Roles, policies, risk assessments, accountability. Something you can audit.

But governance on paper doesn’t stop:

• data leakage

• prompt injection

• broken agents in production

That gap is where AIUC-1 sits.

It focuses on independent technical validation. Not what you say you do, but what your systems actually do when tested.

Simple way to frame it:

• ISO 42001 = how you run AI safely

• AIUC-1 = proof that it’s working

You need both.

The Real Difference

ISO 42001: Structure and control

This is a management system.

It forces you to:

• define ownership

• assess AI risk properly

• document decisions

• set policies for build, deploy and monitor

• create audit trails

• prepare for failure

It’s process-led.

The question it answers is:

Do you have control of AI risk as an organisation?

AIUC-1: Evidence and pressure testing

This is technical.

It tests whether your controls actually work across:

• data and privacy

• security

• safety

• reliability

• accountability

• societal impact

It’s control-led.

The question it answers is:

Can you prove your AI systems behave as expected under pressure?

How They Fit Together in Practice

1. Governance finds risk. AIUC-1 proves you dealt with it.

ISO 42001 will surface the risks tied to your use cases.

Say you’re running a customer-facing agent handling financial data.

You’ll identify:

• data exposure risk

• hallucinations

• prompt injection

• weak audit trails

You’ll put controls in place.

But that’s still theory.

AIUC-1 lets you test those controls:

• Can the agent access data it shouldn’t?

• Can it be manipulated through inputs?

• Does monitoring actually catch bad outputs?

That evidence feeds straight back into your governance.

2. ISO creates accountability. AIUC-1 makes it real.

ISO 42001 forces clarity:

• who owns the risk

• who signs off deployment

• who monitors performance

But accountability without evidence doesn’t stand up.

AIUC-1 gives you something concrete:

Independent validation that your controls work.

That’s what boards, regulators and clients actually care about.

3. Third-party risk becomes manageable

ISO 42001 tells you to manage supplier risk.

That usually turns into:

• long questionnaires

• duplicated assessments

• slow procurement

AIUC-1 changes that dynamic.

• Vendors can show certification instead of answering everything from scratch

• Buyers get a consistent baseline

• You reduce repeat work across the supply chain

It gives your vendor risk process teeth.

4. You stay ahead of regulation instead of chasing it

ISO 42001 gives you a structure that can adapt.

AIUC-1 moves faster, updating regularly against real threats and new rules.

Used together:

• ISO keeps your governance stable

• AIUC-1 keeps your controls current

You’re not reacting to regulation late. You’re already close to where it’s going.

5. This is how you move from policy to reality

A lot of teams get stuck after ISO.

They’ve documented everything. But nothing has really changed on the ground.

AIUC-1 forces operational detail:

• specific evidence

• real testing

• independent audit

• alignment to threat models like MITRE ATLAS

That’s where things sharpen.

You go from “we have controls” to “we know they work”.

How I’d Roll This Out

Phase 1: Get ISO 42001 in place

• define governance

• build your risk register

• set policies and ownership

• establish supplier approach

This gives you structure.

Phase 2: Map AIUC-1 against your risks

• take your risk register

• map controls to AIUC-1 domains

• identify gaps early

Don’t chase certification yet. Just understand the gap.

Phase 3: Build the controls properly

Focus on:

• access control and logging

• adversarial testing

• monitoring and drift

• explainability and auditability

Tie everything back to risk.

Phase 4: Prove it

• gather evidence

• run independent testing

• close gaps

This is where AIUC-1 earns its keep.

Phase 5: Keep it alive

• ISO reviews and updates

• AIUC-1 testing and iteration

Use changes in one to drive the other.

What This Looks Like in the Real World

Take a financial services client running AI agents for customer queries.

ISO 42001 flagged:

• data leakage

• bad advice

• prompt manipulation

• weak traceability

Controls were put in place.

AIUC-1 then tested them:

• tried to break data boundaries

• tested hallucination handling

• pushed prompt injection paths

• validated audit logs

Outcome:

• governance stood up to audit

• controls stood up to testing

• clients trusted the system faster

• internal confidence went up

That’s the difference.

Common Pushback

“Isn’t this duplication?”

No.

One is governance. One is validation.

Without both, you either have:

• structure with no proof

• controls with no oversight

Neither is good enough.

“This feels heavy”

It is work.

But it overlaps more than people think.

• ISO defines what you need

• AIUC-1 proves it

You’re not building two systems. You’re strengthening one.

“We’re not ready”

Then start with ISO.

But build it with testing in mind.

Otherwise you’ll end up rebuilding later.

Where This Is Going

This is heading the same way as:

ISO 27001 and SOC 2.

Governance plus validation becomes standard.

In a couple of years:

• governance alone won’t be enough

• technical validation will be expected

The teams that integrate early will move faster and carry more credibility.

Bottom Line

If you’re responsible for AI risk, this is the job:

Make sure what’s written down matches what actually happens.

ISO 42001 gives you the structure to do that. AIUC-1 gives you the proof.

Used together, you get something that holds up with auditors, regulators and clients.

Used separately, you’re exposed.

If you want a second set of eyes on how to bring both together without slowing delivery, let’s talk.

They write a policy.

It might be called an AI Acceptable Use Policy, an AI Governance Framework or something similar. It will usually look comprehensive. It will be legally careful. It will read well enough for a board pack.

Then, somewhere along the way, people start to believe that because the document exists, governance exists with it.

It does not.

A policy is a statement of intent.

Governance is an operational system.

It is the route a use case takes before approval, the way risk is assessed, the controls that sit around the data, the monitoring after deployment and the person who owns the outcome when the system gets something wrong.

Without structure, the organisation has not governed AI, It has written down what it hopes people will do, and published it hoping it gets sen and read.

That is not enough.

Why policy-first AI governance fails

Policy-first AI governance usually fails for predictable reasons.

There is no formal use case approval process. Risk assessment is informal or inconsistent. Data classification is not mapped to AI usage. Monitoring is vague. Accountability for model output is unclear.

The result is familiar.

Teams deploy AI tools under a policy nobody has really operationalised. Shadow AI continues. Sensitive data moves into places it should not. Boards are told governance exists, while security teams quietly absorb the risk.

That is rarely down to bad intent. It is usually a structural gap.

The organisation has created the words before it has created the working system. It has described the behaviour it wants, but it has not built the mechanism that makes that behaviour normal, repeatable and visible.

Documentation has a place. It gives people boundaries. It sets expectations. It records the organisation’s position.

But it cannot carry the weight alone.

The AI Governance Operating Model

A better way to think about AI governance is as an operating model with four layers:

1. Use case approval

2. Risk assessment

3. Monitoring and oversight

4. Accountability and reporting

Each layer does a different job. Together, they create something practical enough to use and clear enough to defend.

1. Use case approval

Before a tool is selected, the organisation should understand the use case.

What problem is the AI solving? What process will it support? What data will it touch? Who wants it? Who owns it? What happens if the output is wrong?

This is the first place many organisations lose control.

A business team finds a tool that looks useful, starts testing it informally and only brings security or governance into the conversation once momentum has already built. By then, the discussion is no longer about whether the use case is appropriate. It becomes about how quickly it can be approved.

That is backwards, no?

AI adoption should be use-case led, not tool-led.

The organisation needs a clear approval route before teams start moving data, connecting systems or relying on outputs. Without that, AI use spreads through enthusiasm, convenience and local judgement.

That is how shadow AI becomes normal, slips the net, becomes an issue.

2. Risk assessment

Once the use case is clear, the risk needs to be assessed in a consistent way.

This should cover data sensitivity, exposure risk, hallucination impact, misuse scenarios, prompt injection, vendor dependency, regulatory exposure and the consequences of people trusting the output too much.

The key word is consistent.

If one department assesses AI risk carefully and another does it through a quick conversation, the organisation does not have a defensible approach. It has pockets of good practice. That might work for a while, but it will not hold up when a serious question is asked by a board, regulator, client or incident response team.

Risk assessment does not need to be over-engineered.

It does need to be structured.

The same categories should be considered each time. The decision should be recorded. The residual risk should be visible. If the organisation cannot explain why one AI use case was approved and another was rejected, the governance model is not mature enough.

3. Monitoring and oversight

AI governance cannot stop at approval.

Once a use case is live, the organisation needs to understand how it is being used, whether outputs are reviewed, whether human oversight is required and how misuse or drift will be detected.

This is where a lot of governance work becomes theoretical.

The policy says people must use AI responsibly, but nobody is checking whether they are. The risk assessment says outputs should be reviewed, but the operational process does not make that review visible. The approval says sensitive data must not be used, but there is no monitoring route to detect misuse.

And here is where the risk builds.

Oversight does not mean slowing every team down. It means knowing which use cases need close control and which ones can operate with lighter supervision.

A low-risk internal summarisation tool does not need the same oversight as an AI system supporting customer decisions, regulated activity or operational security work.

The level of oversight should match the level of risk.

4. Accountability and reporting

The final layer is accountability.

Someone has to own the use case. Someone has to own the risk. Someone has to decide what level of residual risk is acceptable. Someone has to report AI exposure to leadership in a way that can actually be understood.

This is often the weakest part of AI governance.

Everyone supports responsible AI in principle, but ownership becomes vague when things go wrong. The business owns the process. IT owns the platform. Security owns the risk. Legal owns the policy. Procurement owns the vendor.

That might sound collaborative, but without clear accountability it becomes fragile.

AI governance needs named owners, approved exceptions and a reporting route that gives leadership a real view of exposure. Not just how many AI tools exist, but what they are doing, what data they touch, what controls are in place and where the organisation is accepting risk.

A realistic scenario

Take a simple example.

A customer support team wants to use an AI assistant to summarise support tickets.

On the surface, it looks harmless. It saves time, improves handovers and helps managers spot trends faster.

But the use case may involve personal data, customer complaints, contractual details and commercially sensitive information. If summaries are inaccurate, staff may make poor decisions. If the tool stores prompts or uses them for training, data exposure becomes a concern. If nobody checks the outputs, hallucinated summaries may quietly shape customer outcomes.

A policy might say:

Do not enter sensitive data into unapproved AI tools.

That is useful, but it does not solve the operational problem.

The organisation still needs to approve the use case, assess the data risk, define the oversight model, agree who owns the output and record the residual risk.

That is governance.

The policy supports the system.

It does not replace it.

AI governance readiness checklist

Before writing or refreshing an AI policy, I would assess the operating model underneath it.

Use this as a simple starting point:

• Is there a central register of AI use cases?

• Is there a formal approval route before tools are used?

• Is each use case linked to a business owner?

• Is data classification mapped to AI usage?

• Is there a standard AI risk assessment template?

• Are hallucination and output-decision risks assessed?

• Are prompt injection and misuse scenarios considered?

• Is vendor and model dependency reviewed?

• Is human oversight defined where needed?

• Are monitoring expectations documented?

• Are exceptions recorded and approved?

• Is residual risk visible to leadership?

• Is there a reporting route for AI risk exposure?

• Is ownership clear when AI output causes harm?

If most of those answers are unclear, the organisation does not have an AI governance problem that can be fixed by better wording.

It has an operating model problem.

Structure first. Documentation second.

AI governance is not twelve pages of careful language.

It is the approval path, the risk decision, the monitoring routine, the escalation route and the accountable owner.

The policy still has a place. It sets direction. It tells people what is acceptable. It gives security, legal, risk and business teams a common reference point.

But documentation should describe the governance system.

It should not pretend to be the system.

As AI adoption accelerates, the organisations that mistake paperwork for governance will eventually find the gap.

Usually when a tool is already live, data has already moved and nobody is quite sure who approved what.

Structure first.

Documentation second.

If you want a second set of eyes on your programme, let’s talk.

I moved through roles, contracts and environments that kept adding weight to the same basic foundation: communications, systems, delivery, risk, pressure and people. Cyber security became the obvious name for work I was already circling for years before it appeared properly in my job title.

If you are a service leaver, an engineer, a project manager or someone in an adjacent field looking at cyber, that distinction is worth understanding. A switch can make you feel like you are starting again. Building lets you see the value in what you already carry.

What the Army actually trained me for

I joined the British Army in 1998 and left in 2008 as a Radio Systems Manager, while also serving as a Physical Training Instructor.

Nearly ten years across varied postings, exercises and operational tours gave me a certain way of looking at work. Not a romantic one. A practical one.

Comms systems had to work in environments where they could not just look right on paper. People needed the right information at the right time. Equipment had to be understood, maintained, configured and trusted. There were ranks, personalities, pressure, fatigue and consequence. You had to translate between people who cared about outcomes and people who cared about detail.

You also learned that basics done consistently beat clever plans that fall over when the environment changes.

None of that was cyber security.

All of it shows up in cyber security work every week.

The best security work is not just technical. It is operational. It asks what the system is for, who depends on it, how it can fail, who can abuse it and what happens when something breaks at the wrong time.

That way of thinking was already being built.

The bridge years

I left the Army in 2008 and joined BT Global Services as an Installation Design Consultant. A year later I moved to QinetiQ as a Radio Systems Domain Specialist, working in defence training. Alongside that, I picked up CCNA, CompTIA Network+ and an HNC in Telecommunications.

This is the bit some people skip when they tell pivot stories.

There is usually a stretch where you are not sure where you are heading. You are not where you were and maybe you miss it. I did. But you are not fully where you are going either. You do the work in front of you, and if you pay attention, that work starts shaping the next move.

For me, that stretch was networks, comms design, training and delivery. All relevant later. None of it labelled as cyber at the time.

Looking back, I can see the thread clearly. At the time it just felt like trying to stay useful, keep learning and build something solid after leaving a life that had given me structure.

Africa: where security stopped being theoretical

From 2011 to 2015, I project managed technology installs in places where the threat model was not a slide deck.

First with Ophir Energy, supporting oil and gas exploration drilling operations across land and marine sites. Then with African Minerals in Sierra Leone, running a programme that included server upgrades, CCTV, access control, industrial control systems, fleet management and telecoms on a working mine the width of London.

You do not manage those kinds of projects without thinking about who can get to what, who can shut what off and what happens when something goes down.

You think about access. You think about resilience. You think about recovery. You think about physical and technical dependencies sitting on top of each other. You think about the gap between the drawing and the environment. You think about what a failed system means when people, production, safety and logistics depend on it.

That was cyber security work in everything but the job title.

It was also where I got serious about programme management as a craft. I completed ILM Level 7, APMP, PRINCE2 and MSP in 2014, using up my military learning credits while working between stints away. Partly because the funding was there. Mainly because the work demanded better structure.

The bigger the environment, the less useful vague effort becomes. You need scope, ownership, communication, sequencing and follow-through. You need to finish what gets started.

That has stayed with me.

The cyber role at Bramfitt

I joined Bramfitt Technology Labs in 2018 as a Cyber Security Programme Manager.

The work moved across energy, retail and manufacturing clients. Penetration testing strategy. Cloud migration security. Vulnerability management. Secure development lifecycle. Managed security services. Security control consulting. More recently, AI security and governance.

The threat actors were different and the tooling was sharper, but the operating model felt familiar.

Understand what you are protecting.

Find out how it actually breaks.

Communicate cleanly across the people who need to act.

Finish what gets started.

Certifications followed where they earned their place. CISM. GCCC. ISO 42001 Lead Implementer for the AI governance work. MIT’s AI strategy course for the business framing.

I would like to say I chose them all with a perfect plan. In truth, the path (and boss) chose most of them for me.

That is probably how it should be. Training should serve the work. It should give you language, structure and sharper judgement. It should not become a substitute for delivery.

A simple model for moving into cyber

If you are coming from the military, engineering, infrastructure, project delivery or another adjacent field, do not start by asking whether you are “cyber enough”.

Start with better questions.

What systems have you already been responsible for?

What risks did you have to manage when those systems failed?

Who did you have to communicate with under pressure?

What judgement did the work force you to build?

Where did you already deal with access, resilience, recovery, misuse, dependency or consequence?

Those questions help you find the cyber relevance in your own background without pretending your gaps do not exist.

Because there will be gaps. Of course there will. You may need stronger technical depth, better security language, more familiarity with frameworks, clearer understanding of threat actors or more exposure to testing methods. Fine. Fill the gaps.

But do not confuse gaps with starting from nothing.

A lot of people arrive in cyber with practical experience they have not learned how to name. They have managed critical systems, led projects, dealt with failure, handled pressure, coordinated technical teams and explained risk to people who needed to make decisions.

That counts.

It does not make you finished. It means you have started.

The lesson if you are thinking about a similar move

If you are in service, engineering, infrastructure, project delivery or anywhere adjacent to cyber and wondering whether to switch, you may not need to switch at all.

You may need to identify what you are already doing that counts, name it properly and find an employer who values operational fluency as much as the certification list.

Certs have their place. They give structure, language and a signal that you have done the work to understand the field. But they are not the work itself.

The work is judgement under pressure across complex systems with people who do not always agree.

It is seeing the gap between the diagram and the real environment.

It is understanding what happens when something breaks and who needs to act.

It is knowing that a finding, a risk register or a test report is only useful if it helps someone make a better decision.

If you have done that somewhere else, you are not starting from nothing.

You have already started.

Consultant delivery note

The strongest cyber consultants are rarely just tool operators.

The good ones understand systems, people, pressure, ownership and consequence. Technical skills can be developed, but delivery judgement is harder to teach.

If you already have that from another environment, do not dismiss it. Name it properly. Build the technical gaps. Get around good people. Take the move seriously.

Then carry your weight.