Services / Cybersecurity & Resilience
98% of organisations experienced at least one cloud security breach in the past 18 months. 99% of those breaches were caused by misconfiguration — not by failures in the cloud provider’s infrastructure. The attack surface has not fundamentally changed in character; what has changed is scale and speed. AI tools now allow attackers to discover and weaponise misconfigurations in minutes that previously took days. The organisations that are breached are not, in the main, organisations that failed to invest in security. They are organisations whose security architecture has gaps that were not found by their own processes before they were found by attackers.
A cybersecurity engagement does not make an organisation impenetrable. That is not an achievable state. What it produces is a security posture where the most probable and most consequential attack paths have been identified, the controls that close them have been designed and specified, and the organisation understands what residual risk it is carrying and why. The residual risk will be non-zero. The question is whether it is understood and accepted, or unknown and unpriced.
This service produces security architecture designs, posture assessments, and governance frameworks. It does not operate security tools, manage a SOC, or provide managed detection and response. Those are ongoing operational services that we do not provide. We design the architecture and specify the controls; your team or a managed security service provider operates them.
Price Range
£14,000 – £240,000+
Assessment, architecture design, and governance documentation. Security tooling procurement, SOC operations, and pen testing execution are separate and additional.
Assessment, architecture design, and governance documentation. Security tooling procurement, SOC operations, and pen testing execution are separate and additional.
Duration
4 weeks – 8 months
Depends on engagement type and scope. Implementation of designed controls by your team or MSSP is separate and additional.
Depends on engagement type and scope. Implementation of designed controls by your team or MSSP is separate and additional.
Scope boundary
We assess, design, and document. We do not operate tools, provide managed detection and response, execute penetration tests, or manage a security operations centre. These are procured separately.
Frameworks
NCSC CAF · ISO 27001 · NIS2 · Cyber Essentials+ · DORA · FCA · NHS DSPT · NIST CSF · UK GDPR · PCI DSS
Contract
Fixed-price per engagement. 50% on signing, 50% on delivery acceptance.
What this service does not provideManaged security operations, 24/7 SOC, penetration test execution, vulnerability scanning tools, endpoint detection and response tooling, or SIEM configuration and operation. All of these are operational services that require ongoing staff and tooling — they are procured from MSSPs or specialist providers using the architecture specifications and vendor selection guidance we produce.
How Organisations Actually Get Breached
Not by sophisticated nation-state attacks. By preventable gaps that no one closed.
The majority of breaches affecting organisations of all sizes exploit gaps that are well-understood, technically preventable, and consistently present because identifying and closing them requires sustained operational discipline rather than technical sophistication. The gaps are not secrets. Attackers know where to look because the gaps are documented in the same public frameworks — NCSC, NIST, MITRE ATT&CK — that defenders use. The question is whether the defender has addressed them before the attacker finds them.
01
Credential compromise through phishing and password reuse
The most common initial access vector. A user is phished. Their credentials are captured. Those credentials work on multiple systems because the user reused the password. MFA was either not deployed or was bypassed using a real-time phishing proxy that captures the MFA token alongside the password. The attacker now has valid credentials to multiple systems and appears in logs as a legitimate user.
Frequency
Credential compromise accounts for 86% of web application breaches (Verizon DBIR). 61% of breaches involve credential data. Real-time phishing proxies have made MFA bypass accessible to non-sophisticated attackers — OTP-based MFA is no longer adequate for high-value accounts.
Controls that address this
Phishing-resistant MFA (FIDO2/passkeys) for all privileged and high-value accounts. Conditional access policies that evaluate device health and location at authentication time. Privileged Identity Management with just-in-time access elevation. Credential exposure monitoring against breach databases. User risk scoring in SIEM fed by authentication anomaly detection.
02
Cloud misconfiguration exposing storage, databases, or management interfaces
Storage buckets with public read access. Databases with no IP restriction on management ports. Management interfaces (Kubernetes API servers, cloud console, RDP) exposed to the internet. Security groups that permit inbound access from 0.0.0.0/0. These misconfigurations are introduced at deployment — when the team is focused on making the application work, not on the security baseline — and are then not caught because there is no automated check against a defined security standard.
Frequency
99% of cloud security breaches caused by customer misconfiguration (Gartner). Automated scanning tools allow attackers to enumerate public cloud resources across all three major providers in under an hour. A misconfigured S3 bucket or publicly accessible RDS instance is discovered by automated scanners typically within minutes of creation.
Controls that address this
Cloud Security Posture Management (CSPM) with continuous configuration assessment against a defined security baseline. Policy-as-code that prevents non-compliant infrastructure from being deployed. Security baseline enforced at the landing zone level — misconfiguration is blocked, not just detected. Automated remediation for defined misconfiguration categories. Weekly human review of CSPM findings that automated remediation did not resolve.
03
Unpatched systems exploited through known vulnerabilities
Vulnerabilities with public CVEs and working exploit code, unpatched for weeks or months after disclosure. Organisations that lack a structured patching programme — where patches are applied on an ad-hoc basis when someone remembers, rather than on a defined schedule with tracked compliance — consistently carry a backlog of critical vulnerabilities. The attacker does not need a zero-day when the target is running a version of software whose exploits are published on GitHub.
Frequency
60% of breaches involved a vulnerability for which a patch was available but not applied (Ponemon Institute). Mean time to exploit a critical vulnerability after public disclosure: 15 days. Mean time to patch in most organisations: 60+ days. The window of exposure is typically 45 days of known, exploitable vulnerability.
Controls that address this
Vulnerability management programme with defined SLAs by severity: Critical (CVSS 9+) patched within 24–48 hours; High within 7 days; Medium within 30 days. Automated patch deployment for operating system and common application patches. Exception register for systems that cannot be patched — compensating controls defined and implemented for each exception. Continuous vulnerability scanning, not point-in-time assessments.
04
Lateral movement after initial access — no network segmentation
An attacker who has compromised one endpoint or one credential can, in a flat network, reach every other system. No segmentation limits the blast radius of the initial compromise. The attacker moves laterally from the initial foothold — typically a user endpoint — to higher-value systems: domain controllers, database servers, backup infrastructure. The attack on the high-value target begins weeks after the initial compromise, after the attacker has mapped the network and identified the path of least resistance to their objective.
Frequency
Attacker dwell time before detection: industry average 21 days. In that 21-day window, lateral movement is the primary activity. A segmented network limits the blast radius of the initial compromise to the segment — the attacker must re-compromise to move between segments, which generates more detectable activity and limits the scale of damage achievable before detection.
Controls that address this
Network segmentation aligned to data sensitivity and system criticality: production separated from management, user endpoints separated from servers, backup infrastructure on an isolated segment with no inbound connections from the production network. Zero-trust network access for remote users: no split tunnelling, all traffic through inspection. East-west traffic monitoring between segments with alerting on anomalous traffic patterns. Micro-segmentation for high-criticality workloads.
05
Supply chain compromise through a trusted third party
The target organisation’s security controls are adequate. Their managed service provider, software vendor, or technology supplier’s controls are not. The attacker compromises the supplier — gaining access to the tools, credentials, or software update mechanisms the supplier uses to service the target — and uses that access to reach the target through a trusted, authenticated channel. The target’s monitoring does not flag the access because it appears to come from a trusted source using valid credentials.
Frequency
Supply chain attacks increased 742% between 2019 and 2022 (Sonatype). SolarWinds, Kaseya, MOVEit — each affected thousands of organisations through a single compromised supplier. DORA Article 28 and NIS2 Article 21 both impose explicit third-party security risk management obligations — the regulatory framing now matches the threat reality.
Controls that address this
Third-party risk register with security assessment per supplier, tiered by access level and data exposure. Contractual security requirements for suppliers with privileged access: minimum security standards, right to audit, incident notification obligations within 24 hours. Network segmentation that limits what a compromised supplier can reach. Privileged access management for supplier accounts: just-in-time access, session recording, approval workflow for sensitive operations. Software bill of materials (SBOM) for critical applications.
06
Ransomware deployment after prolonged dwell time
Ransomware is almost never deployed immediately after initial access. The typical sequence: initial compromise (phishing or exploitation), credential harvesting, lateral movement, privilege escalation, backup discovery and destruction or encryption of backup infrastructure, then ransomware deployment across all accessible systems simultaneously. The 21-day average dwell time exists because the attacker needs it to complete this sequence. An organisation that detects and responds to any step in the chain before the final deployment prevents the ransomware. Most organisations detect it at or after the deployment step.
Frequency & Cost
Active ransomware groups increased 49% year-on-year (IBM X-Force 2026). Healthcare is the most targeted sector. Average ransom demand for mid-market organisations: £350,000–£2M. Average total cost including downtime, recovery, and reputational damage: 5–10× the ransom. 65% of organisations that pay the ransom experience a subsequent attack within 12 months.
Controls that address this
Each step of the attacker’s sequence has a detection opportunity: credential harvesting detected by impossible travel and anomalous authentication alerts; lateral movement detected by east-west traffic monitoring and endpoint behavioural detection; privilege escalation detected by privileged account monitoring; backup access detected by backup infrastructure access alerts. Immutable, air-gapped backup architecture (see Disaster Recovery Architecture) limits blast radius even if deployment succeeds. Incident response playbook for ransomware-specific scenarios with pre-approved isolation decisions.
07
Insider threat — intentional or negligent
Insider threat is the category most organisations underinvest in because it is uncomfortable to address and because preventive controls constrain legitimate user behaviour. The negligent insider — the user who emails a client dataset to a personal email address to work from home, or who clicks a phishing link despite training — is statistically far more common than the malicious insider. Both create equivalent exposure. Organisations that do not monitor for data exfiltration patterns because “we trust our employees” are making a statement about trust that is simultaneously reasonable and security-irrelevant.
Frequency & Cost
Insider threat incidents increased 44% over the past two years (Ponemon). Average cost per insider incident: £11.4M for large organisations. 56% of insider incidents are negligent (not malicious) — the most preventable category. Negligent insider incidents are entirely preventable by technical controls; malicious insider incidents require a combination of technical controls and behavioural monitoring.
Controls that address this
Data Loss Prevention (DLP) policies on email and cloud storage: large volume transfers, sensitive data patterns, transfers to personal accounts flagged and where appropriate blocked. User and Entity Behaviour Analytics (UEBA) baseline individual behaviour and alert on deviations: unusual access times, unusual data access volumes, unusual application usage. Privileged user monitoring with session recording for accounts with administrative access. Joiners/movers/leavers process with immediate access revocation on departure — the most commonly neglected control.
08
Incident response that makes the breach worse
The initial breach is one cost. The response to the breach is a second, frequently larger cost. An uncoordinated response where the IT team isolates systems without following a documented sequence destroys forensic evidence. A public statement issued before the scope of the breach is understood creates false representations that must later be corrected. A decision to pay the ransom made under panic rather than following a pre-approved decision framework creates additional exposure. An organisation without a tested incident response plan is not just unprepared for the breach — it is unprepared for the response, which is where most of the controllable cost is.
Cost of poor response
IBM Cost of a Data Breach Report: organisations with a tested incident response plan save an average of £1.5M per breach compared to organisations without one. The saving comes primarily from faster containment, faster notification (reducing regulatory fine exposure), and fewer decisions made under panic that must subsequently be reversed. ICO enforcement: failure to notify within 72 hours of becoming aware of a breach is an independent violation — the cost of a poor notification response is separate from the cost of the breach itself.
Controls that address this
Incident response plan with defined scenarios, response sequences, and pre-approved decision authorities. Specific playbooks for ransomware, data breach, insider incident, and third-party compromise — each with different response sequences and different notification obligations. Tabletop exercises run under realistic pressure conditions — not facilitated discussions, but scenario-driven exercises with time constraints. ICO and regulatory notification timelines pre-coded into the response framework. Ransom payment decision framework approved by the board before it is ever needed.
The Architectural Approach
Zero Trust. What it means in practice and why it is harder to implement than the marketing suggests.
Zero Trust is not a product. It is not a vendor platform. It is an architectural principle: never trust, always verify. Every access request — regardless of where it originates, which network it comes from, or whether the requester has previously been authenticated — is verified against current identity, device health, and context before access is granted. The principle is straightforward. The implementation requires changes to identity architecture, network architecture, application architecture, and operational processes — all of which are more complex and more disruptive to implement than the phrase “Zero Trust” suggests.
Layer 1 — Identity
Verify every user, every time, based on current risk
Phishing-resistant MFA for all users. Conditional access policies that evaluate device health, location, and behavioural risk at every authentication event — not just at login. Privileged Identity Management with just-in-time access: privileged roles are not permanently assigned, they are requested, approved, and granted for a defined window. Continuous access evaluation that revokes sessions when risk signals change mid-session.
Why this is hard to implement
Legacy applications that do not support modern authentication protocols require SAML/OIDC proxy layers that add complexity. FIDO2 rollout requires device replacement or hardware token procurement for users on incompatible devices. Conditional access policies that are too aggressive generate helpdesk volume that creates pressure to loosen them. Just-in-time privilege management requires a cultural change that typically meets resistance from IT staff accustomed to permanent administrative access.
How we design for this
Legacy application authentication proxy design included as a standard component. FIDO2 deployment plan accounting for current device estate and phased rollout. Conditional access policy design calibrated to helpdesk capacity and risk tolerance — policies too aggressive for operational reality will be loosened, producing worse security than a less aggressive policy maintained consistently. Change management requirements documented explicitly.
Layer 2 — Network
Eliminate implicit trust based on network location
Micro-segmentation separating workloads by sensitivity and function — not just perimeter firewall. Zero-Trust Network Access (ZTNA) replacing VPN for remote access: users connect to specific applications, not to the network. All traffic encrypted in transit including east-west traffic within the data centre or cloud environment. Network traffic analysis with baseline modelling and anomaly detection for lateral movement detection.
Why this is hard to implement
Micro-segmentation requires understanding every legitimate network flow in the environment before segmentation can be applied — implementing segmentation without this mapping breaks applications. ZTNA replacement of VPN requires application-level configuration for every application that remote users access — a significant inventory and configuration programme. East-west encryption in a legacy data centre environment often requires network re-architecture. Network baseline modelling for anomaly detection produces high false-positive rates initially that must be tuned over weeks before the alerting is operationally useful.
How we design for this
Network flow mapping before segmentation design — every legitimate flow documented. Segmentation implemented incrementally from highest-value assets outward, not all at once. ZTNA application inventory as a programme prerequisite. East-west encryption phased by environment — cloud first, data centre planned separately. Anomaly detection alert threshold calibration plan included in the architecture — not an afterthought.
Layer 3 — Applications & Data
Protect data at the layer closest to the data
Data classification across all data stores: sensitivity tier, regulatory category, access requirements. Encryption at rest for all classified data — not just in compliance documentation. Data Loss Prevention on egress channels. API security for all externally-facing APIs: authentication, rate limiting, input validation, and anomaly detection. Application-layer access control validated against identity and context at the application, not just at the network perimeter.
Why this is hard to implement
Data classification is consistently the most incomplete component of any security programme because it requires cataloguing data across every system — including shadow systems, legacy databases, and unstructured data stores that no one has inventoried. Encryption at rest for legacy databases requires key management infrastructure and sometimes application changes. DLP policy tuning generates false positives that create user friction and helpdesk load — policies that create too much friction are disabled or bypassed. API security retroactively applied to existing APIs often reveals that the APIs were not designed to support authentication or rate limiting.
How we design for this
Data discovery scan before classification policy — the classification cannot be applied to data that has not been found. Encryption implementation sequenced from highest-sensitivity data. DLP policy design with a defined tuning period and acceptance criteria before policies move from audit to enforcement mode. API security gap analysis as a prerequisite to API security architecture — APIs that cannot support security controls are identified and their remediation or retirement planned before the architecture is designed around them.
Layer 4 — Governance & Compliance
Security that survives staff turnover and audit cycles
Security policies that reflect actual operational constraints — not aspirational statements that are routinely not followed. Security metrics that measure the things that matter: mean time to patch, MFA coverage, privileged account review cadence, vulnerability backlog age. Board-level security reporting that gives the board the information needed to make investment decisions — not compliance theatre. Regulatory framework mapping that produces evidence audit-ready at all times, not assembled in the weeks before an audit.
Why this is hard to implement
Security policies written for audit and security policies followed in practice are consistently different. The CISO knows this; the auditor does not. A security architecture engagement that produces policies without assessing whether they are operationally executable produces policies that exist on paper and are not followed in practice. Board security reporting that does not give the board information they can act on — because the metrics are technical and the context is absent — produces boards that approve security budgets without understanding what they are buying.
How we design for this
Policies designed in collaboration with the operational teams that will follow them — not handed down from security architecture and expected to be adopted. Metrics selected for their decision-relevance to the board, not for their technical completeness. Board reporting template designed to communicate risk and investment return in business terms. Regulatory evidence structured as a continuously-maintained register, not a point-in-time document assembled before each audit.
Zero Trust is a programme measured in years, not a project measured in weeks. A mature Zero Trust implementation requires changes to identity infrastructure, network architecture, application design, operational tooling, and organisational processes. An organisation starting from a conventional perimeter-based security model should plan for a 2–3 year programme to reach meaningful Zero Trust maturity. The architecture design we produce defines the target state and the sequenced path to it. The path is designed to be traversable — not to achieve full maturity on day one, but to move from each stage to the next with measurable improvement in security posture at each step. Where the full programme cannot be resourced, we identify the highest-value initial investments that reduce the most significant exposure within available budget.
Engagement Tiers — Scope, Price, Timeline
Three tiers. Assessment, architecture, and governance. Implementation by your team or MSSP from our specifications.
All three tiers cover the same domains: posture assessment, architecture design across all security layers, governance framework, and regulatory compliance documentation. The tier is determined by organisational size, environment complexity, the number of regulatory frameworks in scope, and whether Cyber Essentials Plus certification is a programme objective. The tooling required to implement the designed architecture is procured separately — we specify which tools are required, what they need to be configured to do, and how their outputs integrate with each other. We do not sell, recommend specific vendors for commercial reasons, or operate tools on your behalf.
Foundation Tier
Foundation Security Programme
For organisations up to 200 staff, single or dual site, seeking Cyber Essentials Plus certification, with one primary regulatory framework and no OT/industrial systems. Typical: SMEs, independent schools, small healthcare providers, small charities, professional services firms. This tier is designed around the NCSC’s 10 Steps to Cyber Security and the Cyber Essentials Plus certification scope — a defensible, documented, tested baseline for organisations that need to demonstrate responsible security posture to funders, clients, and regulators.
£14,000
Fixed · VAT excl.
6 weeksAssumes full access to systems and staff as specified. CE+ certification requires a separate certification body engagement: typically £1,500–£4,000 additional.
Assessment
Security posture assessment across all five control areas: boundary firewalls, secure configuration, access control, malware protection, patch management
Cyber Essentials Plus gap analysis: exact items that would fail a CE+ assessment and what is required to address each
Cloud configuration review: AWS/Azure/GCP misconfiguration assessment against CIS benchmarks for cloud services in use
Credential and identity review: MFA coverage, privileged account audit, joiners/movers/leavers process review
One regulatory framework gap analysis (NCSC CAF, ISO 27001, UK GDPR Art. 32, or DSPT — client selects)
Phishing resilience assessment: review of current phishing training, simulation results if any exist, user vulnerability indicators
Architecture & Documentation
Security architecture design for CE+ scope: specific configuration standards for all five CE+ control areas
Patching programme design: SLAs by severity, responsible parties, exception register process
Access control architecture: MFA rollout plan, privileged account management, joiners/movers/leavers process design
Incident response plan: ransomware, data breach, and phishing scenarios. Response sequences, escalation, ICO 72-hour notification procedure
Security policies: acceptable use, password, BYOD, remote working — written for operational use, not audit exhibition
Regulatory evidence pack for selected framework
Zero-trust network architecture (Foundation tier)
Third-party risk programme
Testing & Certification Prep
1 × tabletop exercise: ransomware scenario, 3 hours, RJV facilitated — tests incident response plan under simulated pressure
CE+ pre-assessment: simulate the CE+ certification assessment against current controls to identify remaining gaps before the formal submission
Remediation guidance for all pre-assessment findings: specific configuration changes per finding
30-day email support after delivery
CE+ certification body engagement (procured separately by client: £1,500–£4,000)
Penetration test execution (available as separate engagement: from £3,500)
NCSC ACD free tools integration (guidance provided; client deploys)
Timeline — 6 Weeks
Wk 1
Posture Assessment
All five CE+ control areas assessed. Cloud configuration review. Credential audit. IT lead interviews.
Read-only access to cloud consoles, endpoint management, firewall configuration, and AD/Entra must be provisioned before week 1 begins.
Wk 2
Gap Analysis & Regulatory Mapping
CE+ gap analysis. Regulatory framework gap analysis. Written findings with severity ratings.
Findings will include items the IT team was unaware of. Common reaction: challenge the findings. Each finding is supported by specific evidence from the assessment — evidence provided with all disputed findings.
Wk 3–4
Architecture & Documentation
Security architecture design. Policies. Incident response plan. All documents issued for client review.
Policies written for operational use generate pushback from staff who prefer less constrained working. This is expected and must be managed — policies that are operationally impossible are not followed, which is worse than no policy.
Wk 5
Tabletop & CE+ Pre-assessment
Ransomware tabletop exercise. CE+ pre-assessment. Findings from both documented.
Tabletop exercises require 4–6 people available for 3 hours. Schedule this in advance. The most common failure mode is the exercise being cancelled or cut short because key people are unavailable.
Wk 6
Handover
Final deliverables. Remediation guidance walkthrough with IT lead. CE+ certification process explained.
CE+ certification body engagement should be booked before week 6 — typical lead time is 3–6 weeks after our pre-assessment confirms readiness.
What Your Team Must Provide
IT lead: 8–12 hours across weeks 1–2 for assessment interviews and system access support
Read-only access provisioned before week 1: cloud consoles, endpoint management platform, firewall management, Active Directory/Entra, email security platform
4–6 staff available for the tabletop exercise in week 5 (3 hours, scheduled minimum 2 weeks in advance)
Document reviews returned within 5 business days
Senior management: available for findings briefing in week 2 (1 hour)
What Is Not in This Tier
CE+ certification body fees: procured separately by the client using our pre-assessment evidence (£1,500–£4,000 typically)
Penetration test execution: available as standalone engagement from £3,500. Required for CE+ if internal vulnerability assessment is not sufficient for the certification body’s requirements.
Implementation of security controls: all implementation by client IT team or MSSP from our specifications and architecture design
MSSP or SOC operational services: procured separately. We provide vendor selection guidance and requirements specification as part of the architecture design.
Second regulatory framework: £3,500 additional
Annual security review (recommended): £5,500/year
Professional Tier
Professional Security Programme
For organisations of 200–2,000 staff, multiple sites, cloud and hybrid environments, ISO 27001 certification target or existing ISMS to be assessed, up to 3 regulatory frameworks, third-party risk programme required. Typical: NHS Trusts, financial services firms, multi-site manufacturers, universities, local authorities, housing associations. Includes zero-trust architecture design as a standard component at this tier.
£72,000
Fixed · VAT excl.
18 weeks baselineISO 27001 certification pathway adds 2–4 months to the programme timeline depending on current ISMS maturity.
Assessment
Comprehensive security posture assessment across all five Zero Trust layers: identity, network, application/data, AI/automation, governance
Cloud security configuration audit across all cloud platforms in use (AWS, Azure, GCP) against CIS benchmarks and CSPM baseline
Identity and access management audit: MFA coverage, privileged access, service accounts, stale accounts, role sprawl
Network segmentation assessment: current segmentation vs required segmentation given data sensitivity and system criticality
Third-party risk assessment: up to 15 critical suppliers assessed against defined security baseline
Up to 3 regulatory frameworks: gap analysis against all three simultaneously, integrated evidence structure
If ISO 27001 is a target: full ISMS gap assessment against all Annex A controls
Architecture & Documentation
Zero-trust architecture design: identity, network, application, and data layers — phased implementation roadmap
CSPM baseline and policy-as-code specification for cloud environments
Vulnerability management programme: SLAs, responsible parties, exception process, reporting cadence
Third-party risk programme: tiering methodology, assessment questionnaire, contractual security requirements, monitoring process
Security incident response plan: 6 scenario-specific playbooks (ransomware, data breach, insider, supply chain, DDoS, credential compromise)
Full security policy suite: 12 policies covering all ISO 27001 governance requirements
If ISO 27001: ISMS documentation framework for all required controls and Annex A implementation statements
Board security reporting template: risk dashboard, investment return framing, regulatory status
Testing & Evidence
2 × tabletop exercises (full day each): ransomware and data breach scenarios with executive participation
Phishing simulation programme design: scenario library, measurement framework, training integration
MSSP/SOC requirements specification: what to procure, what to configure, how outputs integrate with governance
Penetration test scope and requirements specification: your pen test provider executes against our scope document
Compliance evidence packs for all 3 frameworks in audit-ready format
ISO 27001 pre-certification audit preparation (if applicable)
60-day post-delivery support: email plus 2 × advisory calls
Year-1 annual security review included
Timeline — 18 Weeks Baseline (expect 22–26 weeks for organisations with ISO 27001 in scope)
Wk 1–3
Full Posture Assessment
All five layers. Cloud audit across all platforms. Identity audit. Network assessment. Third-party assessments (15 suppliers).
Third-party assessments depend on supplier responsiveness. Suppliers with slow security questionnaire return times extend this phase. Start supplier outreach in week 1, not week 3.
Wk 4–6
Gap Analysis & Regulatory Mapping
Full gap analysis across all three frameworks. Quantified risk exposure per finding. Board briefing on findings.
Board findings briefing must include finance or risk function. Security findings that require significant investment must be presented as a business risk, not a technical requirement.
Wk 7–10
Zero Trust Architecture Design
Full ZT architecture across identity, network, application/data. Phased implementation roadmap. CSPM baseline.
Zero trust architecture design requires network flow mapping before segmentation design. If the current network is not documented, this phase takes longer than estimated.
Wk 11–14
Documentation & Policies
All policies, playbooks, ISMS documents. Two review cycles. Legal and HR review of relevant policies.
HR review of acceptable use and monitoring policies adds 1–2 weeks in organisations where HR has not been previously involved in security governance.
Wk 15–17
Testing Programme
2 × tabletop exercises. Phishing simulation programme design. Pen test scope document. MSSP requirements specification.
Executive participation in tabletop exercises is a requirement, not a preference. Exercises without executive attendance cannot validate the incident response decision-making process.
Wk 18
Handover
Final deliverables. All 3 evidence packs. Implementation sequence guidance. MSSP procurement briefing if required.
MSSP procurement should run in parallel with the programme’s later stages — do not wait until handover to begin vendor selection. Lead time for MSSP procurement and onboarding: typically 6–12 weeks.
What Your Team Must Provide
CISO or IT security lead: 20–30 hours across the programme for assessment interviews, architecture review, and document sign-off
Network team: available for network flow mapping in weeks 7–8 (8–12 hours total)
IT operations: identity audit support in week 2 (4–6 hours), access to AD/Entra, PAM tools, and SIEM if deployed
Legal and HR: 3–4 hours each for policy review in weeks 11–14
Executive team: available for board briefing in week 5–6 and for tabletop exercises in weeks 15–16
15 named critical suppliers: notified in week 1, expected to return security questionnaires within 15 business days
What Is Not in This Tier
Implementation of security controls: all implementation by your team or MSSP from our specifications and architecture design
Penetration test execution: our scope document enables your procured pen test provider to execute; execution is separately procured (typically £8,000–£25,000)
MSSP/SOC operational services: specifications and requirements document provided; procurement and ongoing costs are separate
ISO 27001 certification body fees: typically £8,000–£18,000 for initial certification depending on scope and body
More than 15 third-party supplier assessments: £650/supplier above ceiling
OT/industrial system security: requires Enterprise tier
Year-2+ annual security review: £9,500/year
Enterprise Tier
Enterprise Security Programme
For organisations above 2,000 staff, multi-jurisdiction operations, OT/industrial security requirements, NIS2 essential entity classification, DORA TLPT scope, or organisations that have experienced a significant breach and require post-incident security programme reset. All enterprise engagements individually scoped. The price below is the minimum starting point — actual scope determines actual price.
From £160,000
Individually scoped · fixed · VAT excl.
From 6 monthsEnterprise security programmes with OT scope or post-breach reset commonly run 9–14 months. Scope and timeline agreed at assessment.
What Enterprise Adds
OT/industrial security architecture: IEC 62443 network design, passive-only OT assessment, OT-specific incident response
Multi-jurisdiction compliance: NIS2 essential entity requirements, DORA ICT risk management, cross-border security governance
DORA TLPT programme design (significant entities): scope, scenario design, coordination with accredited TLPT provider
Post-breach programme reset: root cause analysis, architecture remediation, lessons learned integration, regulator engagement support
Supply chain security at enterprise scale: all critical suppliers, SBOM requirements, software composition analysis
Security operating model design: CISO function structure, internal vs MSSP capability split, skills programme
All regulatory frameworks applicable — no cap
Why Enterprise Takes Longer
OT assessment using passive-only methods is slow — active scanning risks disrupting running industrial systems. Allow 4–6 weeks for OT environment assessment alone.
Multi-jurisdiction legal review of security governance in regulated environments requires legal input on different timescales from technical work
DORA TLPT coordination: accredited TLPT providers are booked 3–6 months in advance — programme must account for provider availability
Post-breach programmes require forensic preservation before remediation begins — the sequence is critical and cannot be rushed
Enterprise supply chain assessment at scale: 50+ suppliers with security questionnaire, follow-up assessments for high-risk suppliers, and contractual gap remediation
Enterprise Requirements
Named CISO or equivalent as primary technical sponsor — without security leadership engagement, enterprise programmes stall at the cross-functional boundary
Named C-suite business sponsor: security investment at enterprise scale requires board-level commercial authority
OT team involvement and approval for all OT assessment activities before commencement — no OT assessment activity begins without OT engineering sign-off on method and scope
Legal team sustained availability: NIS2 and DORA compliance work requires legal input at multiple stages, not a single sign-off
Post-breach programmes: legal counsel must be engaged before the technical investigation begins — attorney-client privilege considerations apply to post-breach forensic work
Bilateral Obligations
What both parties commit to.
Client Obligations
Disclose all environments — including shadow IT, personal devices, and unmanaged cloud accounts
The systems most likely to be the initial entry point for an attacker are the systems outside IT governance: the personal cloud storage account used for work files, the unmanaged SaaS tool adopted by a department, the developer’s personal AWS account with a production application running in it. If these are not disclosed, the assessment cannot address them. The attacker does not need to know about IT governance boundaries to find them.
If undisclosed environments are discovered during or after the engagementSystems discovered during the engagement are added to the assessment scope within tier limits. Systems discovered after delivery that were known to exist and were not disclosed: these create a gap in the assessment that we are not accountable for.
Implement controls in the sequence specified, not in a preferred sequence
The implementation sequence in the security architecture is not arbitrary. Controls have dependencies: MFA must be deployed before conditional access policies that depend on MFA signals are enforced; network flow mapping must be complete before micro-segmentation is applied; CSPM must be in monitoring mode before moving to enforcement mode. Implementing controls out of sequence creates either gaps or operational disruptions. If there is a reason to deviate from the sequence, discuss it with us before deviating — not after the disruption occurs.
If the implementation sequence is not followed and disruption resultsWe assess the disruption and the deviation. If the disruption was predictable from the sequence deviation, remediation is outside our scope. If the disruption would have occurred following the sequence, we treat it as an architecture gap and address it.
Security policies that are implemented must be enforceable in the operational environment
We design policies that reflect operational constraints. If a policy requires a control that is technically or operationally impossible for your team to enforce, it will not be enforced — and a policy that is not enforced is worse than no policy because it creates false assurance. Before the policy suite is finalised, we review with the operational team to confirm each control is achievable. If there are constraints we were not told about during this review, the policy will not reflect them, and the gap is a client-side disclosure failure.
If a policy is found to be unenforceable after deliveryReport within 30 days. We review and either revise the policy to an enforceable equivalent control or document the gap and the accepted residual risk.
RJV Obligations
Risk ratings reflect actual risk — not what makes the report comfortable to read
Security assessments consistently produce findings that are rated lower than they should be because high-severity findings create commercial discomfort. A Critical finding requires an uncomfortable conversation about what it means and what it costs to address. We rate findings at the severity warranted by the risk — not the severity that minimises friction in the client relationship. If a finding is Critical, the report says Critical. If the finding would be a reportable incident under NIS2 or UK GDPR if exploited, the report says so.
If you dispute a risk ratingRaise within 10 business days. We review and either confirm the rating with the supporting evidence or revise it if the challenge is substantively correct. Ratings are not revised in response to commercial pressure.
Architecture designs account for your team’s actual capability to implement and operate them
A security architecture that requires skills or tooling your team does not have and cannot acquire within a reasonable timeframe is an architecture that will not be implemented. We design for the team that will implement and operate the controls — not for the security team that could theoretically be hired. Where there is a gap between required and available skills, the architecture includes either a phased approach that builds skills incrementally, or an MSSP procurement requirement that addresses the gap. An architecture your team cannot operate is not a security programme — it is a document.
If a designed control is found to be beyond your team’s implementation capabilityReport within 30 days of delivery. We review and redesign the affected control to an equivalent outcome achievable within your team’s capability or specify the MSSP requirement that makes it achievable. Redesign for capability mismatch is included in the programme fee.
We do not recommend specific security vendors for commercial reasons
Our security architecture is vendor-neutral. We specify the capability required — the function the tool must perform, the integration requirements, the performance criteria — and identify multiple vendors that satisfy those requirements, with the trade-offs between them. We do not have commercial arrangements with security vendors. Where we recommend a specific product, the recommendation is based on the assessment of technical capability for your specific environment — not on a vendor relationship. If you ask why a specific vendor was recommended over an alternative, we will give you the specific technical reasoning.
If you later discover a commercial arrangement we did not discloseThis would be a material conflict of interest and a breach of our engagement terms. If you have evidence of this, raise it and we will investigate and, if confirmed, remediate the affected recommendations at no cost.
Questions that should have answers before any security investment
We already have a firewall, antivirus, and email filtering. Why do we need a security programme?
The 98% cloud breach figure comes from organisations that have those controls. Perimeter controls address a shrinking fraction of the attack surface. A firewall does not protect against credential compromise through phishing — the attacker enters with valid credentials, not by breaking through the firewall. Antivirus does not detect living-off-the-land attacks that use legitimate system tools. Email filtering does not prevent a user from being convinced to visit a malicious link on their phone. The controls you have are necessary but not sufficient. The security programme identifies specifically what the remaining gaps are — not generically, but in your specific environment — and designs the controls that close them.
We had a penetration test last year. Does that replace the security assessment?
No. A penetration test tells you what an attacker with a specific scope, a specific methodology, and a specific time window found. It does not tell you what an attacker with more time and a different methodology would find. It does not assess governance, identity architecture, or third-party risk. It does not produce an architecture design that addresses the findings. And it becomes partially obsolete with every infrastructure change after it was conducted. A security assessment addresses the structural gaps; a pen test validates specific attack paths. Both are necessary. They are not alternatives to each other. Our programme includes a pen test scope and requirements document that enables your procured pen test provider to test effectively against the highest-priority attack paths identified in the architecture assessment.
What is the total cost including tooling and MSSP?
Foundation tier (£14,000 design) plus implementation: CE+ certification body £1,500–£4,000; tooling implementation by IT team or MSSP typically £15,000–£40,000; annual MSSP/SOC costs for an SME typically £18,000–£60,000/year. Professional tier (£72,000 design) plus implementation: penetration test £8,000–£25,000; ISO 27001 certification £8,000–£18,000; MSSP/SOC for a mid-market organisation typically £60,000–£200,000/year; tooling procurement (CSPM, UEBA, DLP) typically £30,000–£120,000/year in licences. Enterprise: total first-year security programme cost including design, implementation, tooling, and managed services typically £500,000–£3M+ depending on scale. The architecture design produces the itemised tooling and services requirements that enable accurate total cost modelling before procurement begins.
We have been breached. Where do we start?
Engage legal counsel before the technical investigation begins — attorney-client privilege protections may apply to the forensic investigation, and this protection cannot be retroactively applied after the investigation has started without legal involvement. Contain first, investigate second: isolate affected systems, but do not wipe them — forensic evidence must be preserved before remediation destroys it. Assess ICO notification obligation: 72-hour clock starts when you become aware of a breach of personal data, not when you understand its full scope — notify early and update the notification as scope becomes clearer. After containment and notification: engage us for a post-breach security programme reset. We assess what happened, how the attacker got in, what they did, and what needs to change to prevent recurrence. Post-breach programmes are available as Enterprise tier engagements, individually scoped to the specific breach and the remediation required.
We are required to achieve Cyber Essentials Plus for a government contract. How long does it take?
From a standing start, assuming no existing CE+ preparation: Foundation tier assessment and architecture (6 weeks) + client implementation of required controls (typically 4–10 weeks depending on gap size) + CE+ pre-assessment and certification body submission (3–6 weeks). Total from engagement start to CE+ certificate: typically 16–24 weeks. If you have a contract deadline within 12 weeks, the timeline is challenging but not impossible — it depends on how close to CE+ compliance you currently are. The discovery session will tell you how large the gap is and whether the contract deadline is achievable.
Can this security programme guarantee we will not be breached?
No. A security programme cannot guarantee the absence of a breach. What it can produce is a security posture where the most probable attack paths have been closed, the residual risk is understood and documented, and the incident response capability means that when a breach occurs — and breaches occur to organisations with mature security programmes as well as to those without — the detection is faster, the containment is faster, and the total cost is lower. The IBM research shows an average saving of £1.5M per breach for organisations with tested incident response plans. That is the realistic value of a security programme: not immunity, but reduced blast radius, faster recovery, and defensible evidence of due diligence in regulatory and legal proceedings.
What are your payment terms?
50% on contract signature, 50% on written acceptance of final deliverables. No milestone payments during execution. Scope additions (additional regulatory frameworks, additional suppliers, additional sites discovered during assessment) are invoiced as agreed in writing before execution — never retrospectively. The final payment is contingent on written acceptance. If a deliverable does not meet the agreed specification, we remediate before raising the final invoice. Annual security review retainers are invoiced annually in advance.
What is the relationship between this service and other RJV services?
Cybersecurity and resilience intersects with all other service areas. DR Architecture (see service page) is the technical capability that enables recovery when security controls fail — the two services are complementary and share the ransomware resilience architecture as a common component. BCP (see service page) incorporates security incident scenarios as a specific continuity category. Cloud Migration (see service page) includes cloud security posture design as a required component. AI Systems Engineering (see service page) addresses AI-specific security risks including agentic AI privilege boundaries. Where multiple services are engaged simultaneously, we design them as an integrated programme rather than parallel workstreams to avoid duplication and ensure the security architecture is consistent across all components.
Start with a security assessment. Bring your last pen test report if you have one — or the fact that you don’t.
A 90-minute session reviewing your current security posture: what controls exist, what the last assessment found, what regulatory obligations apply, and what your highest-risk exposures are. If you have a recent pen test report, we review it in the session — the findings are typically more actionable with context about what the architecture gaps are, rather than addressed in isolation as individual technical remediations. At the end of the session, you have a clear picture of where your posture stands and what the highest-priority investments are.
If you have experienced a breach recently and are in active incident response, contact us by email rather than booking through the standard process — the first response to a live incident is different from a strategic assessment, and we will respond accordingly.
Format
Video call or in-person in London. 90 minutes.
Cost
Free. No commitment.
Lead time
Within 5 business days. For post-breach situations, contact us directly by email for a faster response.
Bring
Most recent penetration test report if available. Cyber Essentials or ISO 27001 assessment results if any. Your current regulatory compliance obligations. Any security incidents from the past 24 months. A rough description of your environment: approximate staff count, sites, cloud platforms in use.
Attendees
Your IT lead or CISO. Optionally, your compliance or legal lead. From RJV: a senior security architect. Not a salesperson.
After
Written summary of session findings within 2 business days. Written scope and fixed price within 5 business days if you want to proceed.