Most organisational security awareness assessments return a single composite score, which quietly rewards programmes for doing a great deal of something while doing nothing about the thing that limits them. The CyberShield Resilience Assessment (CSRA) v2.0 is a free fifteen-item organisational diagnostic that scores a security behaviour programme across the six stages of the SHIELD framework, identifies the constraint stage holding the rest of the programme back, and, through an optional governance module, places the programme on a five-stage maturity scale aligned with the SANS Security Awareness Maturity Model. The maturity stage is gated rather than averaged: a programme sits at the lowest stage its governance permits, and is held there where its practice does not evidence what the stage requires. This note summarises the design, what it reports, and what it does not yet claim.
The problem with an average
A CISO who asks whether the awareness programme is working usually receives an activity report: completion rates, phishing click rates, campaigns delivered. Where a maturity score exists, it is typically a composite in which strength in one area offsets weakness in another. That is the wrong shape for a programme. A programme that has excellent training delivery and no idea which behaviours it is trying to change is not moderately mature; it is constrained at the point of diagnosis, and every downstream activity inherits that constraint. The average hides the thing the leader most needs to know.
The design principle behind the CSRA is borrowed from the theory of constraints (Goldratt & Cox, 1984): the throughput of a system is set by its tightest stage, so the useful output of an assessment is the identity of that stage, not the mean across all of them. The CSRA still reports a score out of 100, because leaders ask for one, but the headline result is the constraint stage, and the maturity module is built so that strength elsewhere cannot lift a programme past a stage its governance and evidence do not support.
Theoretical basis
The instrument is structured around SHIELD, CyBehave's six-stage model of how a behavioural security programme is run: Specify (which behaviours matter and what stops them), Hypothesise (designing interventions from evidence), Intervene (champions, nudges and delivery), Embed (making change persist), Learn (measuring outcomes rather than activity) and Diffuse (how security spreads and sustains without the security team pushing it). The stages are sequential in logic if not always in practice: an intervention designed without a diagnosis, or an evaluation that measures delivery rather than change, is the ordinary way programmes fail.
Three theoretical commitments shape the items. Diagnosis of barriers is anchored on COM-B (Michie et al., 2011), so that a programme scores highly only where it examines capability, opportunity and motivation rather than assuming people fail because they do not care. Champions are treated as a structural feature of the organisation, with the strongest practice being recruitment against informal influence and knowledge of where network coverage is strong and absent. Evaluation is anchored on a predicted effect, so that a programme cannot score highly for measuring activity however carefully it measures it.
Existing validated instruments in this field, such as HAIS-Q (Parsons et al., 2017) and SeBIS (Egelman & Peer, 2015), measure the knowledge, attitudes and behaviour of individuals. The CSRA is deliberately not that. It is a programme-level diagnostic answered by the person who runs the programme, and its unit of analysis is the organisation's practice.
What the assessment asks
The CSRA has fifteen items across the six stages, with more weight given to Specify, Intervene and Learn because those are where programmes most often stall. Every item presents five descriptions of practice ordered from absent to exemplary, and the respondent selects the one closest to reality. Anchors are behavioural rather than evaluative: they describe what the organisation does, not how good the respondent thinks it is, which is what makes the items answerable without a scale of agreement and harder to answer aspirationally.
The definitions are held in a single server-side source and every submission is rescored on the server rather than trusted from the browser, so the score in the benchmark is always the score the server computed.
Scoring and the constraint stage
Each stage receives a normalised score and an overall score out of 100 is reported alongside a maturity band. The constraint stage is the stage with the lowest score, presented on the results screen as a named stage with an explanation of why it limits the others, before the respondent is offered anything else. The overall score is compensatory in the ordinary way, and we say so: it is there because a number is what gets a programme a slot on an agenda. The constraint stage is the diagnostic.
Maturity staging: gated, not averaged
After the SHIELD result, the respondent may answer four optional governance questions covering who owns the programme, where it reports, what leadership actually does, and how often the programme reaches people. These exist because practice items cannot recover the governance facts that the SANS Security Awareness Maturity Model treats as gating. Each answer sets a ceiling on the maturity stage the programme can be placed at, and the programme sits at the lowest ceiling across the four. A well-resourced programme reporting to the CISO that reaches people only through annual mandatory training is a compliance-stage programme, whatever its other answers say, and the assessment reports it as such rather than averaging it up.
Governance answers are self-reported intent, so a second set of evidence rules holds the stage down where the SHIELD profile does not show the practice that stage requires: a programme is not placed at behaviour change without evidence of diagnosis and continuous reach, not at culture change without evidence that change persists and spreads, and not at optimisation without evidence of outcome measurement. Each rule that applies is shown to the respondent under "What is holding you at this stage", with the specific reason and what moves the programme up. The five stage descriptions and the scoring are CyBehave's own; the stage structure is aligned with the SANS model, which is attributed on the results page and in the report.
Benchmarking
Before the questions, the respondent gives three demographics: sector, organisation size band and region. The peer comparison is by sector and size, with region held for future cuts so that cells reach a usable sample. The emailed report includes a peer comparison once enough organisations of the same sector and size have taken the assessment; below that threshold the section is omitted rather than shown on a sample of one.
Data handling
Results are stored anonymised: scores, sector, size band and region, with nothing that identifies the respondent or the organisation. The organisation's name is never requested. An email address is used only to deliver the written report, if the respondent asks for one, and is never stored with the results. The full privacy notice is in the CyBehave Trust Centre.
What the CSRA does not yet do
The CSRA is a designed instrument, not yet a validated one, and it should be read that way. It is self-report by a single respondent, usually the person running the programme, and it inherits the optimism that brings. The evidence rules exist precisely because governance intent and practice diverge, but the practice items are self-reported too. We have not yet run item analysis, reliability estimation or factor analysis on real submissions, so the six-stage structure is theoretically motivated rather than empirically confirmed, and the evidence thresholds were set by expert judgement and will be revisited once the sample allows. The benchmark sample is small and self-selected towards organisations already thinking about behaviour.
None of these limitations affects the central claim. The constraint stage and the gated maturity stage are implemented as described, and a programme cannot be lifted to a stage that any single governance answer, or any evidence rule, does not permit.
What comes next
The validation path runs through Heroes, CyBehave's security champions platform. Heroes measures behaviour from peer pulse surveys of team members rather than champions, network strength from champion surveys and organisational network analysis, and programme capability from the programme lead and delivery records. A CSRA completed by a programme lead can be compared against those independently sourced measures for the same organisation, which is the convergent validity test the instrument needs. The stall pattern the CSRA is designed to expose, at Intervene, Learn and Diffuse, is the pattern Heroes exists to fix.
We will publish item statistics and the benchmark distribution once the real sample is large enough to report without identifying anyone.
References
- Egelman, S., & Peer, E. (2015). Scaling the security wall: Developing a security behavior intentions scale (SeBIS). In Proceedings of the 33rd Annual ACM Conference on Human Factors in Computing Systems (pp. 2873–2882). ACM. https://doi.org/10.1145/2702123.2702249
- Goldratt, E. M., & Cox, J. (1984). The goal: A process of ongoing improvement. North River Press.
- Michie, S., van Stralen, M. M., & West, R. (2011). The behaviour change wheel: A new method for characterising and designing behaviour change interventions. Implementation Science, 6, Article 42. https://doi.org/10.1186/1748-5908-6-42
- Parsons, K., Calic, D., Pattinson, M., Butavicius, M., McCormac, A., & Zwaans, T. (2017). The Human Aspects of Information Security Questionnaire (HAIS-Q): Two further validation studies. Computers & Security, 66, 40–51. https://doi.org/10.1016/j.cose.2017.01.004
- SANS Institute. (n.d.). Security awareness maturity model. https://www.sans.org/security-awareness-training/resources/maturity-model/
Cite this note
CyBehave Lab. (2026). Knowing your weakest stage: the design and implementation of the CyberShield Resilience Assessment. CyBehave Lab. https://cybehave.com/lab/programme-maturity-readiness