Beyond Awareness: Building Cybersecurity Judgement
It is 4:42pm and a finance assistant is clearing the last invoices before the payment run closes. A supplier update looks familiar enough to approve.
Elsewhere, a manager receives an access request from someone already involved in the project, while a shared file appears from a recognised name inside an active conversation.
Nothing looks dramatic. Everything appears to fit the work.
That is why these moments matter.
People rarely face cybersecurity decisions in isolation. They are completing tasks, supporting colleagues and responding to requests that feel routine, useful and expected.
The question is seldom, “Is this a cyber threat?”
It is more often, “Do I carry on, or stop something that appears to make sense?”
Awareness can help people recognise common threats, but recognition alone is not enough when the deadline is real, the request feels legitimate or the approved checking route is difficult to use.
The Cyber Rebels Five-Domain Model was built for that gap. It provides a practical structure for developing the capabilities people need to recognise, verify, act, escalate and judge during real work, while keeping the conditions around the decision visible too.
Why the framework matters
Knowing what people should do is only part of understanding why a cybersecurity decision went the way it did.
Sometimes there is a genuine capability gap. Someone may need more practice recognising when an ordinary request deserves scrutiny, knowing when independent verification is proportionate, completing a task without relying on an unsafe workaround or understanding when uncertainty should be escalated.
But sometimes the person already knows what a safer response would look like and the difficulty sits somewhere else. The verification route may be too slow, responsibility may be unclear, the approved system may not support the task or people may have learned that stopping to question something creates more difficulty than carrying on.
Those are different problems, and they need different responses.
The Five-Domain Model gives us a structure for understanding that difference. Rather than treating cybersecurity as a list of threats to remember, the five domains describe connected capabilities involved when risk appears inside ordinary work.
Someone may first need to recognise that an apparently normal situation deserves attention. They may then need to verify something independently, complete the task through a secure route, raise uncertainty before they know for certain that something is wrong, or make a proportionate judgement where competing priorities do not point neatly in one direction.
Those capabilities rarely appear in isolation.
A supplier payment change, for example, might involve recognising that something deserves another look, confirming the change through an independent route, following the agreed payment process, escalating uncertainty and deciding whether the task should continue.
The surrounding conditions still matter. If the verification route is unavailable, responsibility is unclear or the person is being pushed to prioritise speed, those factors remain part of the decision rather than disappearing behind advice to “be more careful”.
That is the distinction the model helps us make: what does the person need to recognise, understand or do, and what does the organisation need to make possible around them?
It gives Cyber Rebels a consistent way to understand where the difficulty sits and whether the most useful response belongs with learning, process, technology, workload, leadership, governance or a combination of them.
What changes in practice
The Five-Domain Model changes the questions we ask when something goes wrong, nearly goes wrong or repeatedly feels harder than it should.
If someone approves a false payment change, for example, it is easy to begin with the final action and conclude that they should have checked more carefully.
The model takes us further.
Did anything in the request give them a realistic reason to pause? Did they know what needed independent verification? Was there a usable route for doing that? Could they stop the payment without creating another problem? If they were uncertain, did they know who could take ownership?
Those questions help separate different causes that can look identical when we only examine the outcome.
One person may need more practice recognising a change in context. Another may understand the risk perfectly well but be working with a process that makes independent verification unnecessarily difficult. A third may know exactly what to do but be unclear about whether they have the authority to stop the task.
The response should not automatically be the same.
That is where the model becomes useful. It helps us identify whether the most useful next step belongs primarily with learning, process, technology, workload, leadership, governance or a combination of them.
It also gives organisations a more useful way to talk about human risk. Instead of reducing an incident to whether somebody followed the rule, the conversation can focus on what shaped the decision, what capability was needed and what conditions would make the better response easier next time.
The value of the model is not another set of cybersecurity labels. It is a clearer way to understand what happened, what could reasonably have been done differently and where change is most likely to make a practical difference.
Contextual Risk Recognition
Contextual Risk Recognition is the ability to recognise risk when it appears to belong inside normal work.
That matters because most difficult cybersecurity decisions do not begin with something obviously suspicious. They begin with something that fits. An email arrives from a familiar-looking sender. A system prompt appears during a routine task. A colleague shares something that seems expected. A supplier request lands at exactly the point you would expect it to.
The decision is rarely framed as, “Is this a cyber threat?” It is more often, “Do I keep this moving, or do I pause?”
This domain focuses on the subtle signals people need to notice in those moments: social engineering embedded inside normal workflows, familiarity that reduces scrutiny, authority that makes a request harder to question, urgency that pushes speed ahead of checking, and trust in internal or supply-chain relationships that has not yet been independently confirmed.
The aim is not to make people suspicious of everything. It is to help them recognise when something can feel completely normal and still deserve another look.
Someone stronger in this domain is less dependent on obvious red flags. They can explain why something felt legitimate at the time while still identifying what made it risky. They notice when urgency, familiarity or trust is shaping the decision and recognise when they are moving through a task automatically rather than actively evaluating it.
That capability matters because risk often develops before anybody thinks of the situation as security-related. If nothing feels wrong, nothing gets questioned. If the same pattern repeats across people, processes and systems, the exposure can become part of normal work.
The practical shift is small but important: nothing has to look obviously wrong for something to be worth checking.
Where people need more practice recognising those moments, training can help. Where useful signals are repeatedly hidden by interfaces, workload, alert fatigue or the way the work is organised, that surrounding condition needs attention too.
Verification & Control Discipline
Verification & Control Discipline is the ability to apply a proportionate check before acting, particularly when everything already looks legitimate.
An invoice matches expectations. A colleague makes a familiar request. A supplier asks for a change that fits an existing conversation. The quickest and most natural response is simply to continue.
That is what makes verification difficult.
This domain helps people distinguish between something looking right and something having been confirmed properly. It covers independent verification, known-channel confirmation, callback procedures, multi-channel validation, financial authorisation checks and confirmation before sensitive information is shared.
The point is not to create a culture where every routine action needs a second investigation. Good verification is proportionate. It means recognising which decisions carry enough consequence to deserve confirmation and choosing a route that does not depend on the original request being genuine.
For a payment change, that may mean using a previously known contact route rather than replying to the message that requested it. For an access request, it may mean confirming authority through an agreed process. For sensitive information, it may mean checking both who is asking and whether the requested route is appropriate.
Someone stronger in this domain can recognise when familiarity or trust is beginning to replace evidence. They can choose an appropriate independent check, explain why it is proportionate and complete it without turning security into an unnecessary obstacle.
This matters because verification is often skipped for entirely understandable reasons. The person is trying to keep work moving, remain responsive or avoid creating friction around something that already appears correct.
Repeated often enough, that becomes a control problem. Assumption starts to perform the job that verification was supposed to perform.
The model therefore looks at both capability and practicality. People need to know when and how to verify, but the organisation also needs to provide usable routes for doing it. A control that regularly depends on an unavailable person, an inaccessible system or an unrealistic delay will encourage people to improvise around it.
The aim is for verification to become part of doing important work properly, not something added afterwards when a request already feels suspicious.
Secure Operational Behaviour
Secure Operational Behaviour is about the everyday choices people make while using accounts, devices, systems and information.
This is where cybersecurity is often least visible.
A password is reused because another login is needed quickly. MFA is avoided because it adds friction. A personal device is used because the approved one is unavailable. Access is shared because somebody needs to finish a task. Information is sent through an easier route because the normal process is awkward.
None of those actions necessarily feel significant in isolation. They usually feel like practical ways to get the job done.
This domain covers password management, MFA, device handling, remote and hybrid working, data handling and access control. But the real focus is not the technology itself. It is the decisions people make while using it.
Someone stronger in this domain understands why controls exist in the context of their own work. They can recognise when convenience is beginning to shape behaviour, identify where a shortcut introduces unnecessary exposure and choose a safer route that still allows the task to be completed.
They can also recognise patterns rather than seeing each shortcut as an isolated event.
That matters because operational risk often accumulates gradually. A temporary workaround becomes something used every week. Shared access becomes normal because it solves an immediate problem. A convenient data-sharing route becomes the default because nobody has challenged it.
Each individual decision may be understandable. Together they can quietly erode the control the organisation thought it had.
Secure operational behaviour therefore requires more than reminders about passwords or devices. It involves helping people connect small, repeated choices with the wider effect they can have across an organisation.
It also means asking why the shortcut existed in the first place.
If the safer route is usable and someone simply needs more practice applying it, that can be a capability issue. If people repeatedly bypass the same control because the approved route prevents legitimate work from being completed, the organisation has a different problem to solve.
The goal is not perfect behaviour. It is to make secure practice part of how work is normally completed rather than something people have to remember separately from the job.
Incident Judgement & Escalation
Incident Judgement & Escalation is the ability to respond appropriately when something feels wrong before there is enough information to know exactly what has happened.
Most incidents do not announce themselves clearly.
A sign-in page behaves differently. A message feels slightly out of place. A file opens strangely and then seems to work. Someone notices an action they are no longer sure about.
The difficult question becomes: “Is this actually worth raising, or am I making too much of it?”
This domain covers early reporting, escalation routes, responsibility boundaries, near-miss recognition and the initial actions someone may need to take while further help is being sought.
The important capability is being able to act without waiting for certainty.
Someone does not need to diagnose an incident before raising a concern. They need to recognise that something has moved beyond ordinary uncertainty and know who is responsible for taking the next decision.
That also means understanding the limits of their own role. Sometimes the right response is to stop an action, preserve information or disconnect from a process. Sometimes it is simply to report what has happened quickly and allow somebody with the right authority to decide what comes next.
Near misses matter here too. If somebody nearly approves a false request, notices an unusual sign-in and stops, or catches a mistake before information leaves the organisation, that can still reveal something useful about the process or decision that deserves attention.
Hesitation is understandable. People may worry that they are wasting somebody’s time, creating disruption, admitting that they clicked something they should not have, or escalating something that turns out to be harmless.
That is why escalation cannot be treated as an individual capability alone.
People need routes that are easy to find, clear ownership and confidence that a reasonable concern will be taken seriously. If reporting leads to blame, silence or confusion about who owns the issue, hesitation becomes a predictable part of the environment.
The practical shift is from “I need to know something is wrong before I report it” to “I know when uncertainty itself is enough to involve the right person.”
Professional Cyber Judgement
Professional Cyber Judgement brings the other domains together when there is no simple rule that resolves the situation.
Many cybersecurity decisions involve competing priorities rather than an obvious choice between right and wrong.
A request is urgent, but verification will slow it down. A colleague genuinely needs access, but the normal approval route is unavailable. A sensitive piece of information may help someone, but sharing it creates another responsibility. A manager needs to keep a service running while deciding whether a control can reasonably be relaxed.
The question becomes: “What is the proportionate thing to do here, given everything else that matters?”
This domain focuses on the ability to make balanced, defensible decisions under pressure. It includes trade-offs between risk and convenience, ethical responsibility, reputational considerations, safeguarding and the regulatory context that may apply to a particular role or sector.
Someone stronger in this domain can explain not only what they decided, but why. They can recognise the risk, consider the consequences of the available options and balance operational need with appropriate control.
They also know when the decision is no longer theirs to make.
That distinction matters because professional judgement is not permission to ignore controls whenever they become inconvenient. It includes recognising authority boundaries, understanding when an exception requires wider ownership and knowing when the consequences of a choice extend beyond the immediate task.
The ethical and organisational context can matter just as much as the technical one. A decision may affect customer trust, confidential information, safeguarding responsibilities, regulatory obligations or the organisation’s reputation even where the immediate technical risk appears manageable.
Professional judgement therefore asks people to look beyond the quickest successful outcome and consider what the decision commits the organisation to.
It also asks the organisation to recognise when it has placed somebody in an unreasonable position. Staff should not repeatedly have to invent exceptions, choose between service delivery and security without support, or carry responsibility for a trade-off that properly belongs with management or governance.
This domain is where recognition, verification, operational behaviour and escalation come together. The aim is not flawless judgement. It is the ability to make a proportionate choice, explain the reasoning, remain accountable for the decision and involve wider authority when the situation requires it.
That is the point at which cybersecurity becomes part of professional responsibility rather than a separate set of rules remembered only when something looks obviously dangerous.
How the Model Shapes Cyber Rebels Training
The Five-Domain Model sits underneath how Cyber Rebels designs and delivers behaviour-led training, but it does not assume that training is the answer to every problem.
We begin with the decisions people are likely to make in their actual roles. Rather than explaining threats in isolation, we look at where those threats become difficult to recognise or act on: during a rushed approval, a familiar request, a system prompt, a payment change, a workaround or an uncertain moment somebody is not sure whether to report.
The domains help us identify where the difficulty sits.
Someone may need more practice recognising risk in context or understanding when a separate check is proportionate. A team may need clearer shared judgement around escalation. A workaround may have become normal because it solves a genuine operational problem. In each case, the training can be shaped around the capability that needs strengthening rather than defaulting to generic awareness content.
At the same time, we look at what the organisation makes possible around that decision. Verification routes need to be usable. Responsibilities need to be understood. Systems and controls need to fit the work, and people need visible support when they pause, question or raise uncertainty.
Most real situations involve more than one domain.
A supplier payment change might involve recognising that something deserves another look, independently verifying the request, following the agreed payment process, escalating uncertainty and making a judgement about whether the task should continue.
That is why the model separates capability from organisational enablement. Training is used where people need opportunities to recognise, interpret, verify, practise, escalate or judge. Where the issue sits with process, technology, workload, leadership or governance, that remains visible rather than being turned into another thing the individual should simply have known.
The content may change according to the role, environment and decisions people face, but the purpose stays consistent: help people develop practical judgement they can use during real work, while helping organisations understand what needs to exist around them for the better response to be realistic.