Risk has an owner
Under Secure by Design, every service has risk owners. They are senior people, accountable for its cyber risk throughout its life.
Government and defence
Secure systems for government, built on public guidance
I have worked on government, transport and public sector projects, from the Network Rail data centre to a council network. This page explains the public rules behind that kind of work: how information is classified, who may see it, and how risk is owned and assured. Every diagram can be stepped through at your own pace.
Overview
Start by mapping the whole system
Public guidance keeps returning to one idea: understand the system, make it hard to attack, and assume something will still get through. The National Cyber Security Centre (NCSC) publishes secure design principles that set this out in five categories.
Swipe sideways to see the whole diagram.
Everything starts here. Map every user, device, supplier, data flow and dependency first, so the defences have no blind spots.
Every way into the service is known and controlled. Input from outside is checked at the edge, so an attack stops at the boundary.
The service is built to cope with spikes in use and with denial of service attacks. A second instance carries the load, so one failure or flood does not take it down.
Logs from every part go to monitoring, so suspicious activity is spotted while it is happening.
Assume something gets in. An inner segment limits what a compromised front end can reach, and the data only accepts the one flow it needs.
Secure from the start
Security is built in from the first day of delivery and kept up through the life of the service.
Assume something gets through
Defence in depth, and limits on what one foothold can reach, mean that a single failure is never the whole story.
Classifications
Three tiers, three threat levels
The Cabinet Office's Government Security Classifications Policy has three tiers. As the tier rises, so do the threat considered, the vetting needed and the protective controls. Choose a tier.
Swipe sideways to see the whole diagram.
OFFICIAL. Most information created or handled in the public sector sits here. It must be protected against a broad range of threat actors. Anyone working with it has a Baseline Personnel Security Standard (BPSS) check, but no national security vetting is needed.
SECRET. Protection against sophisticated, well resourced and determined threat actors, including capable state actors, some serious organised crime groups and insiders. Regular or uncontrolled access needs Security Check (SC) clearance, and the controls are enhanced.
TOP SECRET. Information facing the highest level of threat, so very little risk can be tolerated. Regular or uncontrolled access needs Developed Vetting (DV), and the policy expects highly secured, dedicated physical infrastructure.
Not a fourth tier
OFFICIAL-SENSITIVE is a marking on OFFICIAL information that is of interest to threat actors and not meant for public release. It is not a separate classification, and the information stays OFFICIAL.
Controls add up
Each tier's controls are cumulative and form the foundation for the next. A higher tier adds to the base and never replaces it.
Volume matters
Large aggregated sets of OFFICIAL data may need extra controls, because aggregation increases the impact if the data is misused.
Vetting
National Security Vetting, one level at a time
Classification protects the information. Vetting checks the people who handle it. Each level adds checks to the one below, as described publicly by United Kingdom Security Vetting.
Swipe sideways to see the whole diagram.
The Baseline Personnel Security Standard is not a formal clearance. The employer checks identity, right to work, employment history and unspent criminal records. All government staff and contractors need it, or an equivalent.
A Counter Terrorist Check is for posts close to public figures at particular risk from terrorism, or with access to material of value to terrorists or to establishments at risk of attack. It adds a security questionnaire and a check of Security Service records.
Security Check is for long term, frequent and uncontrolled access to SECRET, and occasional supervised access to TOP SECRET. It adds a credit and financial history check.
Developed Vetting is for frequent, uncontrolled access to TOP SECRET. It adds a full financial review, a detailed interview and interviews with referees. Enhanced versions of SC and DV exist for a small number of posts.
Clearance belongs to the role: the department decides what level a post needs. I am SC eligible, and willing to undergo SC vetting.
Frameworks
Five frameworks, and when each applies
They overlap, but each answers a different question. Choose one to see how it is built, who publishes it and where it fits.
Swipe sideways to see the whole diagram.
Cyber Assessment Framework (CAF)
- Published by
- NCSC. Version 4.0, reviewed on 6 August 2025.
- What it is
- Four objectives and 14 principles for judging how well cyber risk to essential functions is managed.
- When it applies
- Organisations responsible for essential functions. Central government departments are assessed against it through GovAssure: a self assessment against a Government CAF profile, then an independent assurance review.
- Use it to
- Assess outcomes rather than tick boxes. Its indicators of good practice are a starting point for discussion.
Cloud Security Principles
- Published by
- NCSC.
- What it is
- 14 principles to help choose a cloud provider that meets your security needs, for cloud platforms and software as a service.
- When it applies
- Choosing and assessing any cloud service.
- Use it to
- Compare providers on the same terms. Configuring the chosen service securely is a separate job for the customer.
Cyber Essentials
- Published by
- NCSC.
- What it is
- The minimum standard of cyber security the government recommends for organisations of all sizes, built on five technical controls.
- When it applies
- Central government has required it for some contracts since 2014. Procurement Policy Note (PPN) 014 replaced PPN 09/14 from 24 February 2025. It covers higher risk contracts, such as those that handle citizens' personal data or supply systems that store or process OFFICIAL data. It is also the first step in Defence Cyber Certification.
- Use it to
- Set a baseline for every supplier. Cyber Essentials Plus adds independent testing that the controls work in practice.
ISO/IEC 27001
- Published by
- ISO and IEC. The current edition dates from 2022.
- What it is
- Requirements for establishing, implementing, maintaining and continually improving an information security management system (ISMS).
- When it applies
- Any organisation, whatever its type or size.
- Use it to
- Run security as a managed system with risk assessment and treatment, rather than as a one off project.
Secure by Design
- Published by
- UK government, on security.gov.uk. MOD publishes its own approach for defence.
- What it is
- Ten principles that build security into digital services from the start and throughout their life.
- When it applies
- Mandatory for government departments and arm's length bodies, and optional for the rest of the public sector.
- Use it to
- Name accountable risk owners early, then keep gathering evidence that the controls work.
Architecture patterns
Moving data between levels of trust
NCSC publishes patterns for joining systems that are trusted to different levels. This is its pattern for safely importing data, step by step, drawn as a generic example rather than any real system.
Swipe sideways to see the whole diagram.
The pattern starts on the low side. Complex content is converted into a simpler format there, because parsing untrusted data is risky. Bring across only the data the business needs.
The external network connection and application protocol end here. Only the payload moves on, over a simple protocol, which makes protocol attacks on the destination much harder.
Flow control, such as a data diode, lets data move in one direction only. It marks the line between the low side and the high side, and makes command and control or data export much harder.
After the one way flow, a carefully built verifier checks that the content is valid and is what was expected. It is the final step before the destination.
Only content that passes verification reaches the destination system. Each control in the chain adds confidence, so no single component has to carry all the trust.
Content that fails verification goes no further. Each side logs to its own monitoring, so no logs flow back down. A verification failure raises an alert, because it suggests the transform has failed or been compromised.
Based on NCSC's Pattern: Safely Importing Data and its cross domain design principles. A generic illustration, not a real system.
Administer from a trusted device
Swipe sideways to see the whole diagram.
Browse up. NCSC lists this as an anti pattern. Systems are managed from the same device used for email and the web, so one phishing email can lead straight to production.
Browse down. Production is managed only from a device you trust, and riskier browsing happens in a separate, less privileged place. NCSC publishes principles for these privileged access workstations.
Other public patterns
- Separate by trust. Systems trusted to different levels are kept apart and joined only through controlled gateways like the one above.
- Protect the management plane. Management traffic gets the same layered defences as user traffic. NCSC lists management bypass as an anti pattern.
- Watch everything. Collect logs centrally, protect them from tampering, and use them to raise alerts on the threats you expect.
- Trust no network. NCSC's zero trust principles include knowing every user, service and device identity, and not trusting any network, including your own.
- Constrain third parties. NCSC's answer to supplier access is a good contract, constrained access and a thorough audit trail.
- Keep it patchable. Build in enough redundancy to patch little and often, without long outages.
Boundaries
Not every boundary is equally strong
A security boundary sits wherever trust, ownership or classification changes, and every crossing must be allowed and logged. The controls that make a boundary range from a line in a switch configuration to physically separate networks. These are general, published principles, drawn as a generic example.
Swipe sideways to see the whole diagram.
VLAN and access list. A virtual LAN (VLAN) with an access control list (ACL) is fine for separating groups inside one security domain. Because the separation is only configuration on shared hardware, one mistake joins the two sides, so it is never the boundary between classifications.
VRF. With virtual routing and forwarding (VRF), each side gets its own routing table, so there is no path unless routes are leaked or a firewall joins them. The equipment, software and administrators are still shared.
Stateful firewall. Every crossing is checked against allow rules and logged, with a default deny. This is the usual boundary between zones of different trust within one organisation.
Separate networks. Each domain has its own equipment, cabling and administration, and only an approved gateway joins them, such as the import pattern above. Separation by logical features, such as virtual device contexts on one chassis, shares the supervisor and software, so I do not treat it as equal to this.
Link encryption. Where a domain's traffic must cross a network it does not trust, encryptors at each end protect it. The encryptor is itself a boundary: the protected side and the bearer side have separate addressing and routing. For government data, the products are assured by NCSC for what they carry. Layer 2 encryptors protect Ethernet frames, much like MACsec (Media Access Control security), and Layer 3 encryptors protect IP packets, much like IPsec (IP Security).
Accidental bridges I design out
- A host with network cards in two domains.
- A patch lead in the wrong port, so I use colour coding, labelling and port security.
- A trunk carrying a VLAN it should not.
- One management network shared across domains.
- A virtual machine with network cards in two domains, or a shared virtual switch.
- Shared storage, backup or monitoring that reaches both sides.
- Removable media and wireless, controlled by policy and technology.
Bringing updates onto an isolated network
- Official source. Download from the vendor's own site.
- Check the hash. Compare it with the vendor's published value, such as SHA-512.
- Approved route. Move it through a cross domain import or registered media, scanned on a dedicated station and logged.
- Check again inside. Recheck the hash on the isolated side before use.
- Test, then change. Test in a reference environment, then deploy through change control.
People at different levels
Where staff work at several levels, each classification has its own network and end points, or an approved multi level solution. Within a network, access follows need to know: role based access, directory groups, 802.1X and firewall rules.
Micro segmentation inside a domain
Inside one domain, micro segmentation contains lateral movement and lets a suspect machine be quarantined by tag while it stays up for investigators. It strengthens a domain. It never replaces an accredited boundary between domains.
Security operating procedures
Every system has security operating procedures: the rules its users and administrators follow. I write the technical parts with the design, so the procedures and the network say the same thing.
Assurance
Every service has a risk owner and ongoing checks
Secure by Design treats security as a loop that runs for the whole life of a service. Each step below maps to its principles.
Swipe sideways to see the whole diagram.
It starts with responsibility. Each service has risk owners: senior people with the knowledge and authority to lead on security, accountable for its cyber risk throughout its life.
Risk drives the design. The threats, the impact and the classification of the information decide which controls are proportionate.
Controls are designed to be usable and layered, with a small attack surface. Detection and response are built in rather than added later.
Evidence that the controls work is gathered all the time, not once before go live. Delivery teams record it in a Secure by Design self assessment.
Every change is made securely and fed back to the risk owner, so the loop starts again. MOD describes security as an ongoing part of a capability's whole life.
How central government checks itself: GovAssure
GovAssure launched in April 2023. It is how government organisations check the cyber security of their own critical systems against the CAF. It covers critical systems at OFFICIAL, and systems at SECRET and above are out of scope. It runs in five stages, in a fixed order.
Swipe sideways to see the whole diagram.
The organisation starts a scoping document. It sets out its mission, the context it works in and the essential services it is responsible for.
It identifies the critical systems those services rely on and chooses which to assess this year. Each one gets a Government CAF profile: Basic or Enhanced. Critical national infrastructure (CNI) systems must have Enhanced.
The organisation completes a self assessment in WebCAF for each system it is putting through GovAssure this year.
An independent reviewer checks the self assessment against the scoping document and the evidence. Lead government departments, and arm's length bodies with government CNI, must use one. Others can use a peer review. Each system gets a report with observations, its achievement against the target profile and recommendations.
The organisation records actions that answer the review's recommendations in a Targeted Improvement Plan, using WebCAF. Then the cycle starts again.
Supply chain
Security that reaches every supplier
Government and defence contracts pass security requirements down to suppliers. In defence, Defence Cyber Certification builds on Cyber Essentials in four levels, assessed against the Defence Standard known as Def Stan 05-138.
Swipe sideways to see the whole diagram.
The government's recommended minimum standard is also the entry point for defence suppliers. Every Defence Cyber Certification level starts with it.
Defence Cyber Certification was developed by MOD with IASME and is assessed against Def Stan 05-138 (Issue 4, May 2024). The scheme launched in May 2025. Level 0 has 3 controls and Level 1 has 101.
The higher levels have 139 and 144 controls and need Cyber Essentials Plus, with its independent technical testing. A higher level also satisfies every level below it.
Certification is backed by an annual attestation and a full recertification every three years. Industry Security Notice 2026/02 (March 2026) tells MOD buyers to accept it as evidence under Defence Condition (DEFCON) 658.
A principle in its own right
The CAF lists supply chain under managing security risk, and NCSC's cloud principles include supply chain security.
Constrained supplier access
For third party access, NCSC advises a good contract, constrained access and a thorough audit trail of what suppliers do.
Contracts carry the rules
PPN 014 sets when central government buyers ask for Cyber Essentials. In defence, DEFCON 658 calls for evidence against Def Stan 05-138.
The wider rules for critical services
Critical national infrastructure
The UK groups its critical national infrastructure into sectors such as energy, water, transport, communications, finance, health, food, defence and government. Data centres were added as critical national infrastructure in 2024. Operators of essential services fall under the Network and Information Systems (NIS) Regulations 2018, telecoms providers under the Telecommunications (Security) Act 2021, and EU operations under NIS2.
The UK bodies involved
NCSC is the UK's technical authority for cyber security and publishes the CAF. NPSA, the National Protective Security Authority, which replaced the Centre for the Protection of National Infrastructure (CPNI), covers physical and personnel security. NPL, the National Physical Laboratory, keeps the UK's time standard, which matters when logs and trades must be timed precisely.
Checking a supplier
I ask for evidence, not promises: a SOC 2 (System and Organization Controls 2) report on the supplier's controls, the exact scope of any ISO 27001 certificate, Cyber Essentials Plus, and contract terms for audit, access and exit. A certificate covers a management system, not a product.
Engagement
How I run a secure public sector engagement, built on public frameworks
On government and defence work the method matters as much as the design. I follow the published frameworks, keep risk owners involved at every step, and make sure the evidence for assurance is produced as the work happens, not afterwards.
Swipe sideways to see the whole diagram.
I start by agreeing the system's context: what it does, what data it holds and at what classification, and who owns the risk. For a central government department that is GovAssure stages 1 and 2, which give each system a Government CAF profile, Basic or Enhanced.
Functional requirements describe the service. Security requirements come from the risk assessment and the framework outcomes, and each one is traced to a risk, a control and a test, so assurance can follow the thread.
I map the current assets, data flows, boundaries and suppliers, then baseline them against the CAF outcomes, in WebCAF where GovAssure applies. Credentialed scans and hardening checks show the real state. Gaps are recorded with the risk they create, not just the missing control.
Designs use published patterns, such as NCSC's guidance for joining systems of different trust, and record every risk decision with the risk owner. Anything that departs from a pattern is explained in writing, then accepted explicitly.
Every change is built to the approved design and produces its own evidence: configuration, tests and approvals. An independent IT Health Check tests the boundaries and fixes are retested before the risk owner accepts the service into live running.
Live running follows the security operating procedures: who may change what, how incidents are reported and how changes are approved. Monitoring and reporting feed the regular assurance cycle, so the risk owner always has a current view.
Assurance is continuous. Under GovAssure each cycle ends with an Independent Assurance Review of the self assessment, then a Targeted Improvement Plan for the gaps. Between cycles the system is patched, kept within support, and its suppliers are reviewed.
Functional requirements
What it must do.
- Give access only to authorised users on managed devices, with multi factor authentication, at the classification the system is approved for.
- Separate domains of different classification with physically separate networks, joined only through an assured gateway.
- Give administrators a separate management network and a recorded admin path, never from the user network.
- Import and export data only through approved patterns, with content checked at the gateway.
- Send boundary rule hits, admin sessions and authentication events to protective monitoring.
- Give suppliers only the access the contract allows, through the same recorded admin path.
Non functional requirements
How well it must do it, with a number wherever one can be agreed.
- Assurance
- Evidence for each framework outcome, kept current and ready for review.
- Availability
- Targets set by how essential the service is, with tested recovery.
- Separation
- Boundaries tested independently before live running and after major change.
- Monitoring
- Security events collected centrally, with agreed response times.
- Patching
- Critical and high security updates within 14 days, as Cyber Essentials requires, with exceptions approved.
- Supply chain
- Suppliers meet the contract's security clauses, such as Cyber Essentials Plus.
Typical starting points. Each organisation's policy and risk appetite set the real targets.
Who I talk to
- Senior risk owner and information asset owners
- Security, assurance and audit teams
- Service owners and user representatives
- Infrastructure and operations teams
- Suppliers, integrators and managed service providers
How I find out
- Context workshops: what the system does and what is at stake
- Asset and data flow mapping, checked against discovery scans
- Discovery scans only with the system owner's written approval, from an approved device in an agreed window
- NCSC Cyber Assessment Framework self assessment, outcome by outcome
- Cyber Essentials checks of the five controls
- Document review: policies, designs, procedures and past assessments
- Supplier and contract review
Discovery tools
| Tool or source | What it tells me |
|---|---|
| NCSC CAF self assessment (WebCAF under GovAssure) | How each system measures against the outcomes for its CAF profile, and where the gaps are. |
| Cyber Essentials checks | Firewalls, secure configuration, user access control, malware protection and security update management, with critical and high patches within 14 days. |
| Nmap host discovery, in an agreed window | Live hosts and open ports on each segment, checked against the asset register. |
| Tenable Nessus or Qualys, credentialed | Missing patches against the patching policy. |
| Center for Internet Security (CIS) benchmarks with CIS-CAT, or the vendor's hardening guide | Drift from the approved build. |
| NetFlow records and firewall rule hit counts | Which flows really cross each boundary, and which rules are never used. |
| NCSC Early Warning service | Known compromise or exposure reported for the organisation's IP ranges and domains. |
| Past IT Health Check reports and supplier evidence | Known weaknesses and whether they were fixed, and the scope of each supplier certificate. |
On secure networks a fault is fixed within the rules, never around them. A quick workaround that bridges a boundary is a bigger problem than the outage.
My approach
- Define. What is affected, since when, and what changed? Check the change records first.
- Stay inside the rules. Work within the security operating procedures and the approved access path, even under pressure.
- Follow the path. Trace the flow through each boundary in order: switch port, firewall, gateway, then encryptor, with the log at each.
- Prove the cause. Use the boundary's own tools: rule hit counts, the gateway's content verification log and the encryptor's tunnel state, before changing anything.
- Fix through change. Apply the fix through change control. An emergency change still needs approval and a record.
- Report and learn. Report any security relevant finding through the agreed route, and record the cause.
Faults I see most
- A boundary rule that does not match a new or changed data flow
- Certificates expired on a gateway or encryptor
- Clock drift breaking authentication or log correlation
- An import blocked because content failed verification
- A supplier change that was not reflected in the design
- Patching delayed because of a fragile dependency
Layer by layer
| Layer | What I check |
|---|---|
| 1 and 2 · Physical and data link | Cabling, ports and VLANs, checked against the approved design and labels. |
| 3 · Network | Routing per VRF, and proof that each domain's table holds only its own prefixes, so no path leaks between domains. |
| 4 · Transport | Boundary firewall sessions and rule hits, in both directions. |
| 5 and 6 · Session and presentation | Certificates and keys on encryptors and gateways: validity, certificate revocation list (CRL) reachability and key expiry. |
| 7 · Application | Application logs, identity and authorisation results. |
My general method is on the troubleshooting page.
Secure services are supported through clear procedures, so nobody has to improvise during an incident.
Procedures
Security operating procedures for users and administrators, kept in step with the design.
Access
Named accounts, a controlled admin path and recorded sessions for all support staff.
Incidents
A clear route for reporting security incidents, separate from routine faults where policy requires.
Change
Every change approved and evidenced, including emergency changes.
Suppliers
Supplier access limited to what the contract allows, and reviewed regularly.
Reporting
Regular reports to the risk owner on incidents, changes, vulnerabilities and open risks.
Assurance is a cycle, not an event. I plan the whole life of the system around it.
- Reassess. A GovAssure or CAF reassessment on the agreed cycle, with a Targeted Improvement Plan for the gaps.
- Patch. Critical and high security updates within 14 days, with exceptions recorded and approved by the risk owner.
- Retest. An IT Health Check after major change and on a regular cycle, with every finding tracked to closure.
- Supplier reviews. Supplier evidence and contracts reviewed at agreed intervals.
- End of life. Kit replaced before vendor support ends, with secure disposal of every storage device.
- Retire. When a system retires, data is archived or destroyed, and accounts and records are closed.
Projects
Where I have done this kind of work
These are the projects in my career closest to this page: government, transport and public sector work, regulated change and design authority.
Government and transport projects
I led 3 engineers on finance, transport and government projects. They included the £25M Network Rail data centre, built from an empty shell.
Network Rail among my clients
Network Rail was one of my clients at XIDA. In that role I was lead architect on network, cloud and data centre modernisation programmes across several clients, from discovery to operational handover.
Public sector network modernisation
I modernised a council network across switching, wireless and firewalls, leading 7 engineers and third party suppliers.
Regulated change with no outages
I delivered the Europe, Middle East and Africa (EMEA) network refresh, from audit through high and low level design to implementation. The estate stayed compliant with the Markets in Financial Instruments Directive II (MiFID II) throughout, with no service outages.
Design authority standards
As lead network and security transformation architect, I set the design authority standards adopted by every regional delivery team. I led 7 engineers and architects and coordinated 5 vendors.
Security and delivery
I have passed the Cisco Certified Internetwork Expert (CCIE) Security written exam, and I am a Cisco Certified Specialist in Security Core. I also hold PRINCE2 Practitioner and ITIL.
SC eligible: UK resident throughout my career and willing to undergo SC vetting. See all credentials
Sources
Public guidance behind this page
Everything on this page comes from public guidance. The diagrams are generic and describe no real system. I checked each source in October 2026.
- Government Security Classifications Policy, Cabinet Office, version 2.0 (August 2024)
- National Security Vetting clearance levels, United Kingdom Security Vetting
- Secure design principles, NCSC
- Cyber Assessment Framework, NCSC
- Cyber Assessment Framework 4.0 (PDF), NCSC
- GovAssure guidance, security.gov.uk
- GovAssure stage 2: in scope systems and CAF profiles, security.gov.uk
- GovAssure launch, April 2023, Civil Service World
- The cloud security principles, NCSC
- Cyber Essentials overview, NCSC
- Procurement Policy Note 014: Cyber Essentials scheme, Cabinet Office, February 2025
- ISO/IEC 27001:2022, IEC webstore
- Secure by Design principles, security.gov.uk
- About Secure by Design, security.gov.uk
- What is Secure by Design?, MOD
- Pattern: Safely Importing Data, NCSC
- Cross domain design principles, NCSC
- Principles for secure privileged access workstations, NCSC
- Security architecture anti patterns, NCSC
- 10 Steps: logging and monitoring, NCSC
- Zero trust architecture design principles, NCSC
- Defence Cyber Certification, IASME
- One year of Defence Cyber Certification, Defence Digital blog
- Industry Security Notice 2026/02: Defence Cyber Certification (DCC) under DEFCON 658, MOD
- Cyber security for defence suppliers, Def Stan 05-138 Issue 4, MOD
- Defence Cyber Protection Partnership, MOD
Explore
More areas I design and deliver
Every page follows the same idea: how it works, the choices that matter, and where I have used it. The foundations pages explain the basics the others build on.