What GovAssure Actually Asks For
GovAssure asks a government organisation to prove, system by system, that it achieves a defined set of cyber security outcomes — 41 of them, grouped into 14 principles and four objectives — and then to have an independent reviewer check that the proof holds. It is not a checklist and it is not a certification. It is an evidence exercise, and organisations lose marks on evidence far more often than on controls.
This is what each part of it actually asks for.
What GovAssure is, precisely
GovAssure is the UK government’s scheme for assessing the cyber security of government critical systems against the NCSC’s Cyber Assessment Framework. It was developed by the Government Security Group in the Cabinet Office with the NCSC, and is now overseen by the Government Cyber Unit, which moved from DSIT to the Department for Digital, Culture, Media and Sport in the recent machinery-of-government changes. The GovAssure team has said the previously announced timelines are unchanged. (It is pronounced as it reads: gov-assure.)
Three boundaries are worth fixing in your head before you start.
It covers OFFICIAL systems only. It is explicitly not suitable for systems processing information at SECRET and above.
It is per-system, not per-organisation. You choose how many critical systems to put through in a given year, and each one gets its own assessment, its own profile and its own improvement plan.
It assesses government organisations. If you are a supplier, GovAssure is not run on you. You are reached through principle A4, and through the evidence your customer has to produce. More on that below.
Each in-scope system is assigned a Government CAF profile, Baseline or Enhanced. Baseline is the minimum for every government organisation and is built to mitigate largely non-targeted attacks. Enhanced layers on additional Indicators of Good Practice for systems where the risk owner expects capable, persistent, well-resourced attackers, and is driven by threat profile, CNI status, system criticality and the criticality of the data involved. Choosing the wrong profile at Stage 2 makes every judgement downstream wrong, which is why it is worth arguing about early. Getting that call right is the first thing our CAF and GovAssure readiness work fixes.
How the scoring actually works
The CAF is built as outcomes, not controls. The current version is v4.0, released 4 August 2025. It contains four objectives, 14 principles and 41 contributing outcomes.
Each contributing outcome is scored Achieved, Partially Achieved or Not Achieved, judged against Indicators of Good Practice. To reach Achieved, all the IGP statements in that column must be true. To be marked Not Achieved, only one statement in that column has to be true. That asymmetry is the single most misunderstood thing about CAF scoring, and it is why organisations with genuinely good security still come out amber.
The detail most self-assessments miss: nine of the 41 contributing outcomes have no Partially Achieved column at all. They are binary.
| Two-state outcome | Principle |
|---|---|
| A1.a Board Direction | Governance |
| A1.b Roles and Responsibilities | Governance |
| A1.c Decision-making | Governance |
| A2.c Assurance | Risk Management |
| A3.a Asset Management | Asset Management |
| D1.b Response and Recovery Capability | Response and Recovery Planning |
| D1.c Testing and Exercising | Response and Recovery Planning |
| D2.a Post Incident Analysis | Lessons Learned |
| D2.b Using Incidents to Drive Improvements | Lessons Learned |
Governance and incident response give you nowhere to hide. There is no partial credit for a half-finished asset inventory or an untested response plan.
Objective A — Managing security risk
Nine contributing outcomes across four principles. This is the objective that fails on paperwork.
A1 Governance (A1.a Board Direction, A1.b Roles and Responsibilities, A1.c Decision-making) asks whether security is directed at board level, whether roles and escalation routes are established and understood, and whether accountability sits with someone senior with the authority to decide. All three are binary. Evidence that satisfies: board minutes showing cyber risk discussed and decisions taken, a documented escalation path someone can actually describe when asked, and a named senior owner. Where it fails: a policy signed by a board that has never discussed it.
A2 Risk Management (A2.a Risk Management Process, A2.b Understanding Threat, A2.c Assurance) is where the CAF diverges hardest from a controls checklist. A2.b asks you to understand the capabilities, methods and techniques of threat actors relevant to your essential functions, and to show that understanding changing your decisions. A generic threat report bought from a vendor does not achieve this. A2.c, Assurance, and binary, asks how you gained confidence that your controls work. Penetration testing, technical validation and audit evidence sit here. Assertion does not.
A3 Asset Management (A3.a, binary) asks for an inventory complete enough to manage, operate and recover the essential function, including dependencies between asset types. The IGPs mark you Not Achieved if inventories are incomplete, if dependencies between IT and OT are not understood, or if knowledge critical to recovery is held by one or two people with no succession plan. That last one catches a great many otherwise competent teams.
A4 Supply Chain (A4.a Supply Chain, A4.b Secure Software Development and Support) is covered in its own section below.
Objective B — Protecting against cyber attack
Twenty contributing outcomes across six principles, and the largest single block of work.
B1 splits policy development (B1.a) from implementation (B1.b), and B1.b asks you to demonstrate the security benefit achieved, not that the policy exists. B2 covers identity in four parts: verification and authorisation (B2.a), device trust (B2.b), privileged user management (B2.c) and identity and access management as a discipline (B2.d). B3 runs to five outcomes covering understanding your data (B3.a), data in transit (B3.b), stored data (B3.c), mobile data (B3.d) and sanitisation before reuse or disposal (B3.e). B4 covers secure by design (B4.a), secure configuration (B4.b), secure management (B4.c) and vulnerability management (B4.d). B5 covers resilience preparation (B5.a), designing for resilience with appropriate segregation (B5.b) and backups (B5.c). B6 covers culture (B6.a) and training (B6.b).
Objective B is where the gap between a documentation-led readiness review and a real one shows up. Almost every outcome here is a technical claim: that privileged access is closely managed, that configuration is secure, that segregation holds, that backups restore. A reviewer at Stage 4 will ask for evidence. Testing the control produces that evidence. Describing it does not.
Objective C — Detecting cyber security events
Seven outcomes, and disproportionately hard for smaller organisations.
C1 Security Monitoring carries six of them: log sources and tooling (C1.a), securing the logs themselves including retention and deletion (C1.b), generating alerts (C1.c), triage (C1.d), the skills of the people doing monitoring including outsourced staff (C1.e), and understanding normal user and system behaviour alongside threat intelligence (C1.f).
Two of those are routinely underestimated. C1.b asks that log data is held securely, access-restricted to business need, retained for a suitable period and then deleted, which is a retention policy question as much as a technical one. C1.e explicitly reaches into your outsourced SOC: the framework asks whether monitoring personnel, including those outsourced, have sufficient knowledge of your systems and the essential functions they protect. “We have a managed SOC” is the start of that answer, not the end of it.
C2 is now named Threat Hunting (C2.a) in CAF v4.0, and asks for proactive discovery that goes beyond pattern matching.
Objective D — Minimising the impact of incidents
Five outcomes, four of them binary.
D1 covers the response plan (D1.a, the only three-state outcome in the objective), the capability to actually enact it (D1.b), and testing and exercising (D1.c). D2 covers post-incident analysis (D2.a) and using what you learn to drive improvement (D2.b).
D1.c is the one that most often turns an otherwise strong assessment amber. It asks that you carry out exercises using past incidents, your own and other organisations’, and scenarios drawn from threat intelligence and your risk assessment. A plan that has never been exercised cannot achieve it, and there is no partial credit available.
What happens between self-assessment and independent review
The GovAssure process runs in five stages, in order.
| Stage | What happens |
|---|---|
| 1 | Define your organisation’s context, mission and essential services; begin the scoping document |
| 2 | Identify the critical systems those services rely on, decide how many to assess this year, and assign each a Baseline or Enhanced profile |
| 3 | Complete the self-assessment in WebCAF |
| 4 | Independent Assurance Review — a third-party reviewer verifies the self-assessment |
| 5 | Build a Targeted Improvement Plan in WebCAF, one per system |
Lead Government Departments and organisations with government-sector CNI get a dedicated GovAssure cyber adviser through stages 1 to 3, and work with their reviewer through stages 4 and 5.
Stage 4 is where preparation pays or does not. You hand the reviewer your scoping document and all relevant evidence, and they verify what you claimed. The final report for each system contains the reviewer’s observations, your achievement against the target profile, and recommendations. Stage 5 then turns those recommendations into recorded actions.
Three procedural points catch organisations out.
Lead Government Departments and organisations with government-sector CNI must use an independent assurance reviewer. Other organisations can use a Peer Review process instead, which has its own Stage 4 and Stage 5 guidance.
Reviewers must be Assured Service Providers on the NCSC’s Cyber Resilience Audit scheme. Nobody else is eligible to deliver an Independent Assurance Review.
Procurement takes longer than people plan for. The guidance directs you to the Government Commercial Agency’s Cyber Security Services 3 agreement, filtered for CRA, and tells you to start as early as possible in the GovAssure year. Departments that leave it late compress Stage 4 into the time they needed for remediation.
There is also a structural point worth stating plainly. Readiness work and the independent review are different roles, and the same firm should not do both. A readiness partner that also offers to sign off your Stage 4 is offering to mark its own homework.
If you are a supplier, not a department
Suppliers do not go through GovAssure. They are reached three ways.
Through A4.a. The outcome asks the department to understand and manage supplier risk to the systems supporting its essential functions. Read the Achieved column and you can see exactly what your customer will need from you: they must know the extent of the supply chain including sub-contractors; you must be able to demonstrate appropriate and proportionate cyber security in the context of capable, well-resourced threat actors; relevant contracts must carry appropriate security obligations; customer and supplier ownership of responsibilities must be defined in contracts; all network connections and data sharing must be managed; and where appropriate, your incident management process and theirs must provide mutual support. The Enhanced profile adds coordination with suppliers on incident triage and resolution, and explicit consideration of sub-contractor risk.
If you have been sent a supplier assurance questionnaire that reads oddly, that is why. It is A4.a working backwards, and it is the same rigour we apply in supply chain assurance engagements. It bites hardest in the defence supply chain, where the department above you is likely to be on the Enhanced profile.
Through A4.b. Secure Software Development and Support asks whether your software supplier understands the composition and provenance of what they ship, whether updates arrive through secure channels, whether there is a vulnerability disclosure and mitigation process, and, at Achieved, whether they use an established secure development framework and can attest to the authenticity and integrity of their software. If you build software for government, this is now assessed.
Through procurement. PPN 014, whose provisions in-scope organisations have applied since 24 February 2025, requires suppliers to hold Cyber Essentials or Cyber Essentials Plus — or demonstrate equivalent controls — for contracts where ICT systems or services store or process data at OFFICIAL. Where certification is required it must be renewed annually for the duration of the contract, and the evidence matters at the point data is passed to you, not at the point of award. The PPN is equally clear that it must not be applied as a blanket requirement to every contract.
Where the handbook lags the framework
The Government Cyber Security Policy Handbook restructures government policy and technical guidance into CAF language, principle by principle. It is the most useful single document for working out what a department is expected to do, and it sits beneath the GovS 007: Security functional standard.
It is also not synchronised with the CAF. Two examples, both current as this is published:
- The handbook’s principle list still names C2 as “Proactive Security Event Discovery”, its CAF v3.x title. NCSC renamed it Threat Hunting in v4.0.
- The handbook’s A4 page, last updated 12 November 2024, cites PPN 09/23 as the mandate for Cyber Essentials. That PPN was replaced by PPN 014 in February 2025.
Neither changes what you have to do, but both change what you should cite. If your self-assessment quotes the handbook as its authority, check the framework version underneath it before a reviewer does.
How we approach it
We do the readiness work: scoping and profile selection, a full gap analysis scored across all 14 principles the way an assessor will score it, technical validation of the Objective B and C outcomes by testing the controls rather than reading about them, and a prioritised remediation plan tied to the evidence a reviewer will ask for.
We do not deliver Stage 4. The Independent Assurance Review is a CRA-gated role and a deliberately independent one, and we say so plainly. Our job is to make the review a confirmation rather than a surprise.
If you have a GovAssure year ahead of you, start with a CAF gap analysis.