Skip to main content

Report

Cost & Sustainability

How does your organisation allocate capacity for production workloads in the cloud?

Peak Provisioning: Capacity is typically provisioned based on peak usage estimates, potentially leading to underutilisation during off-peak times.

How to determine if this good enough

When an organisation provisions capacity solely based on the highest possible load (peak usage), it generally results in:

  1. High Reliance on Worst-Case Scenarios

    • You assume your daily or seasonal peak might occur at any time, so you allocate enough VMs, containers, or resources to handle that load continuously.
    • This can be seen as “good enough” if your traffic is extremely spiky, mission-critical, or your downtime tolerance is near zero.

  2. Predictable But Potentially Wasteful Costs

    • By maintaining peak capacity around the clock, your spend is predictable, but you may overpay substantially during off-peak hours.
    • This might be acceptable if your budget is not severely constrained or if your leadership prioritises simplicity over optimisation.

  3. Minimal Operational Complexity

    • No advanced autoscaling or reconfiguration scripts are needed, as you do not scale up or down dynamically.
    • For teams with limited cloud or DevOps expertise, “peak provisioning” might be temporarily “good enough.”

  4. Compliance or Regulatory Factors

    • Certain government services may face strict requirements that demand consistent capacity. If scaling or re-provisioning poses risk to meeting an SLA, you may choose to keep peak capacity as a safer option.

You might find “Peak Provisioning” still acceptable if cost oversight is low, your risk threshold is minimal, and you prefer operational simplicity. However, with public sector budgets under increasing scrutiny and user load patterns often varying significantly, this approach often wastes resources—both financial and environmental.

How to do better

Below are rapidly actionable steps to reduce waste and move beyond provisioning for the extreme peak:

  1. Implement Resource Monitoring and Basic Analytics

  2. Pilot Scheduled Shutdowns for Non-Critical Systems

    • Identify development and testing environments or batch-processing servers that don’t require 24/7 availability:
    • Sharing this data with stakeholders can highlight the discrepancy between peak and average usage, demonstrating immediate cost savings without impacting production systems.

  3. Explore Simple Autoscaling Solutions

Implementing autoscaling in a controlled environment allows you to evaluate its benefits and challenges, providing valuable insights before considering broader adoption for more critical workloads.

  1. Review Reserved or Discounted Pricing

    • If you must maintain consistently high capacity, consider vendor discount programs to reduce per-hour costs:

      • AWS Savings Plans or Reserved Instances: AWS offers Savings Plans, which provide flexibility by allowing you to commit to a consistent amount of compute usage (measured in $/hour) over a 1- or 3-year term, applicable across various services and regions. Reserved Instances, on the other hand, involve committing to specific instance configurations for a term, offering significant discounts for predictable workloads.

      • Azure Reservations for VMs and Reserved Capacity: Azure provides Reservations that allow you to commit to a specific VM or database service for a 1- or 3-year period, resulting in cost savings compared to pay-as-you-go pricing. These reservations are ideal for workloads with predictable resource requirements.

      • GCP Committed Use Discounts: Google Cloud offers Committed Use Discounts, enabling you to commit to a certain amount of usage for a 1- or 3-year term, which can lead to substantial savings for steady-state or predictable workloads.

      • OCI Universal Credits: Oracle Cloud Infrastructure provides Universal Credits, allowing you to utilise any OCI platform service in any region with a flexible consumption model. By purchasing a sufficient number of credits, you can benefit from volume discounts and predictable billing, which is advantageous for maintaining high-capacity workloads.

    • Implementing these discount programs won’t eliminate over-provisioning but can soften the budget impact.

  2. Engage Leadership on the Financial and Sustainability Benefits

    • Present how on-demand autoscaling or even basic scheduling can reduce overhead and potentially improve your service’s environmental footprint.
    • Link these improvements to departmental net-zero or cost reduction goals, highlighting easy wins.

Through monitoring, scheduling, basic autoscaling pilots, and potential reserved capacity, you can move away from static peak provisioning. This approach preserves reliability while unlocking efficiency gains—an important step in balancing cost, compliance, and performance goals in the UK public sector.

Manual Scaling Based on Average Consumption: Capacity is provisioned for average usage, with manual scaling adjustments made seasonally or as needed.

How to determine if this good enough

This stage represents an improvement over peak provisioning: you size your environment around typical usage rather than the maximum. You might see this as “good enough” if:

  1. Periodic But Manageable Traffic Patterns

    • You may only observe seasonal spikes (e.g., monthly end-of-period reporting, yearly enrollments, etc.). Manually scaling before known events could be sufficient.
    • The overhead of full autoscaling might not seem worthwhile if spikes are infrequent and predictable.

  2. Comfortable Manual Operations

    • You have a change-management process that can quickly add or remove capacity on a known schedule (e.g., scaling up ahead of local council tax billing cycles).
    • If your staff can handle these tasks promptly, the organisation might see no urgency in adopting automated approaches.

  3. Budgets and Costs Partially Optimised

    • By aligning capacity to average usage (rather than peak), you reduce some waste. You might see moderate cost savings compared to peak provisioning.
    • The cost overhead from less frequent or smaller over-provisioning might be tolerable.

  4. Stable or Slow-Growing Environments

    • If your cloud usage is not rapidly increasing, a manual approach might not yet lead to major inefficiencies.
    • You have limited real-time or unpredictable usage surges.

That said, manual scaling can become a bottleneck if usage unexpectedly grows or if multiple applications need frequent changes. The risk is human error (forgetting to scale back down), delayed response to traffic spikes, or missed budget opportunities.

How to do better

Here are rapidly actionable steps to evolve from manual seasonal scaling to a more automated, responsive model:

  1. Automate the Manual Steps You Already Do

    • If you anticipate seasonal peaks (e.g., quarterly public reporting load), replace manual processes with scheduled scripts to ensure timely scaling and prevent missed scale-downs:

      • AWS: Utilise AWS Step Functions in conjunction with Amazon EventBridge Scheduler to automate the start and stop of EC2 instances based on a defined schedule.

      • Azure: Implement Azure Automation Runbooks within Automation Accounts to create scripts that manage the scaling of resources during peak periods.

      • Google Cloud Platform (GCP): Leverage Cloud Scheduler to trigger Cloud Functions or Terraform scripts that adjust instance groups in response to anticipated load changes.

      • Oracle Cloud Infrastructure (OCI): Use Resource Manager stacks combined with Cron tasks to schedule scaling events, ensuring resources are appropriately managed during peak times.

    • Automating these processes ensures that scaling actions occur as planned, reducing the risk of human error and optimising resource utilisation during peak and off-peak periods.

  2. Identify and Enforce “Scale-Back” Windows

    • Even if you scale up for busy times, ensure you have a defined “sunset” for increased capacity:
      • Configure an autoscaling group or scale set to revert to default size after the peak.
      • Set reminders or triggers to ensure you don’t pay for extra capacity indefinitely.

  3. Introduce Autoscaling on a Limited Component

    • Choose a module that frequently experiences load variations within a day or week—perhaps a web front-end for a public information portal:

      • AWS: Implement Auto Scaling Groups with CPU-based or request-based triggers to automatically adjust the number of EC2 instances handling your service’s load.

      • Azure: Utilise Virtual Machine Scale Sets or the AKS Cluster Autoscaler to manage the scaling of virtual machines or Kubernetes clusters for your busiest microservices.

      • Google Cloud Platform (GCP): Use Managed Instance Groups with load-based autoscaling to dynamically adjust the number of instances serving your front-end application based on real-time demand.

      • Oracle Cloud Infrastructure (OCI): Apply Instance Pool Autoscaling or the OKE Cluster Autoscaler to automatically scale a specific containerised service in response to workload changes.

    • Implementing autoscaling on a targeted component allows you to observe immediate benefits, such as improved resource utilisation and cost efficiency, which can encourage broader adoption across your infrastructure.

  4. Consider Serverless for Spiky Components

    • If certain tasks run sporadically (e.g., monthly data transformation or PDF generation), investigate moving them to event-driven or serverless solutions:

      • AWS: Utilise AWS Lambda for event-driven functions or AWS Fargate for running containers without managing servers. AWS Lambda is ideal for short-duration, event-driven tasks, while AWS Fargate is better suited for longer-running applications and tasks requiring intricate orchestration.

      • Azure: Implement Azure Functions for serverless compute, Logic Apps for workflow automation, or Container Apps for running microservices and containerised applications. Azure Logic Apps can automate workflows and business processes, making them suitable for scheduled tasks.

      • Google Cloud Platform (GCP): Deploy Cloud Functions for lightweight event-driven functions or Cloud Run for running containerised applications in a fully managed environment. Cloud Run is suitable for web-based workloads, REST or gRPC APIs, and internal custom back-office apps.

      • Oracle Cloud Infrastructure (OCI): Use OCI Functions for on-demand, serverless workloads. OCI Functions is a fully managed, multi-tenant, highly scalable, on-demand, Functions-as-a-Service platform built on enterprise-grade infrastructure.

    • Transitioning to serverless solutions for sporadic tasks eliminates the need to manually adjust virtual machines for short bursts, enhancing efficiency and reducing operational overhead.

  5. Monitor and Alert on Usage Deviations

    • Utilise cost and performance alerts to detect unexpected surges or prolonged idle resources:

      • AWS: Implement AWS Budgets to set custom cost and usage thresholds, receiving alerts when limits are approached or exceeded. Additionally, use Amazon CloudWatch’s anomaly detection to monitor metrics and identify unusual patterns in resource utilisation.

      • Azure: Set up Azure Monitor alerts to track resource performance and configure cost anomaly alerts within Azure Cost Management to detect and notify you of unexpected spending patterns.

      • Google Cloud Platform (GCP): Create budgets in Google Cloud Billing and configure Pub/Sub notifications to receive alerts on cost anomalies, enabling prompt responses to unexpected expenses.

      • Oracle Cloud Infrastructure (OCI): Establish budgets and set up alert rules in OCI Cost Management to monitor spending. Additionally, configure OCI Alarms with notifications to detect and respond to unusual resource usage patterns.

    • Implementing these alerts enables quicker responses to anomalies, reducing the reliance on manual monitoring and helping to maintain optimal resource utilisation and cost efficiency.

By automating your manual scaling processes, exploring partial autoscaling, and shifting spiky tasks to serverless, you unlock more agility and cost efficiency. This approach helps ensure you’re not left scrambling if usage deviates from seasonal patterns.

Basic Autoscaling for Certain Components: Autoscaling is enabled for some cloud components, primarily based on simple capacity or utilisation metrics.

How to determine if this good enough

At this stage, you’ve moved beyond purely manual methods: some of your workloads automatically scale in or out when CPU, memory, or queue depth crosses a threshold. This can be “good enough” if:

  1. Limited Service Scope

    • You have identified a few critical or high-variance components (e.g., your front-end web tier) that benefit significantly from autoscaling.
    • Remaining workloads may be stable or less likely to see large traffic swings.

  2. Simplicity Over Complexity

    • You deliberately keep autoscaling rules straightforward (e.g., CPU > 70% for 5 minutes) to avoid over-engineering.
    • This might meet departmental objectives, provided the load pattern doesn’t vary unpredictably.

  3. Reduced Manual Overhead

    • Thanks to autoscaling on certain components, you rarely intervene during typical usage spikes.
    • You still handle major events or seasonal shifts manually, but day-to-day usage is more stable.

  4. Partially Controlled Costs

    • Because your most dynamic workloads scale automatically, you see fewer cost overruns from over-provisioning.
    • You still might maintain some underutilised capacity for other components, but it’s acceptable given your risk appetite.

If your environment only sees moderate changes in demand and leadership doesn’t demand full elasticity, “Basic Autoscaling for Certain Components” can suffice. However, if your user base or usage patterns expand, or if you aim for deeper cost optimisation, you could unify autoscaling across more workloads and utilise advanced triggers.

How to do better

Below are actionable ways to upgrade from basic autoscaling:

  1. Broaden Autoscaling Coverage

    • Extend autoscaling to more workloads to enhance efficiency and responsiveness:

      • AWS:

        • EC2 Auto Scaling: Implement EC2 Auto Scaling across multiple groups to automatically adjust the number of EC2 instances based on demand, ensuring consistent application performance.
        • ECS Service Auto Scaling: Configure Amazon ECS Service Auto Scaling to automatically scale your containerised services in response to changing demand.
        • RDS Auto Scaling: Utilise Amazon Aurora Auto Scaling to automatically adjust the number of Aurora Replicas to handle changes in workload demand.

      • Azure:

        • Virtual Machine Scale Sets (VMSS): Deploy Azure Virtual Machine Scale Sets to manage and scale multiple VMs for various services, automatically adjusting capacity based on demand.
        • Azure Kubernetes Service (AKS): Implement the AKS Cluster Autoscaler to automatically adjust the number of nodes in your cluster based on resource requirements.
        • Azure SQL Elastic Pools: Use Azure SQL Elastic Pools to manage and scale multiple databases with varying usage patterns, optimising resource utilisation and cost.

      • Google Cloud Platform (GCP):

        • Managed Instance Groups (MIGs): Expand the use of Managed Instance Groups with autoscaling across multiple zones to ensure high availability and automatic scaling of your applications.
        • Cloud SQL Autoscaling: Leverage Cloud SQL’s automatic storage increase to handle growing database storage needs without manual intervention.

      • Oracle Cloud Infrastructure (OCI):

    • Gradually incorporating more of your application’s microservices into the autoscaling framework can lead to improved performance, cost efficiency, and resilience across your infrastructure.

  2. Incorporate More Granular Metrics

  3. Implement Dynamic, Scheduled, or Predictive Scaling

    • If you observe consistent patterns in your application’s usage—such as increased activity during lunchtime or reduced traffic on weekends—consider enhancing your existing autoscaling strategies with scheduled scaling actions:

    • Implementing scheduled scaling allows your system to proactively adjust resources in anticipation of predictable workload changes, enhancing performance and cost efficiency.

    • For environments with variable and unpredictable workloads, consider utilising predictive scaling features. Predictive scaling analyzes historical data to forecast future demand, enabling the system to scale resources in advance of anticipated spikes. This approach combines the benefits of both proactive and reactive scaling, ensuring optimal resource availability and responsiveness.

      • AWS: Explore Predictive Scaling for Amazon EC2 Auto Scaling, which uses machine learning models to forecast traffic patterns and adjust capacity accordingly.

      • Azure: While Azure does not currently offer a native predictive scaling feature, you can implement custom solutions by analyzing historical metrics through Azure Monitor and creating automation scripts to adjust scaling based on predicted trends.

      • GCP: Google Cloud’s autoscaler primarily operates on real-time metrics. For predictive capabilities, consider developing custom predictive models using historical data from Cloud Monitoring to inform scaling decisions.

      • OCI: Oracle Cloud Infrastructure allows for the creation of custom scripts and functions to implement predictive scaling based on historical usage patterns, although a native predictive scaling feature may not be available.

    • By integrating scheduled and predictive scaling strategies, you can enhance your application’s ability to handle varying workloads efficiently, ensuring optimal performance while managing costs effectively.

  4. Enhance Observability to Validate Autoscaling Efficacy

    • Instrument your autoscaling events and track them to ensure optimal performance and resource utilisation:

      • Dashboard Real-Time Metrics: Monitor CPU, memory, and queue metrics alongside scaling events to visualise system performance in real-time.

      • Analyze Scaling Timeliness: Assess whether scaling actions occur promptly by checking for prolonged high CPU usage or frequent scale-in events that may indicate over-scaling.

    • Tools:

      • AWS:

        • AWS X-Ray: Utilise AWS X-Ray to trace requests through your application, gaining insights into performance bottlenecks and the impact of scaling events.

        • Amazon CloudWatch: Create dashboards in Amazon CloudWatch to display real-time metrics and logs, correlating them with scaling activities for comprehensive monitoring.

      • Azure:

        • Azure Monitor: Leverage Azure Monitor to collect and analyze telemetry data, setting up alerts and visualisations to track performance metrics in relation to scaling events.

        • Application Insights: Use Azure Application Insights to detect anomalies and diagnose issues, correlating scaling actions with application performance for deeper analysis.

      • Google Cloud Platform (GCP):

        • Cloud Monitoring: Employ Google Cloud’s Operations Suite to monitor and visualise metrics, setting up dashboards that reflect the relationship between resource utilisation and scaling events.

        • Cloud Logging and Tracing: Implement Cloud Logging and Cloud Trace to collect logs and trace data, enabling the analysis of autoscaling impacts on application performance.

      • Oracle Cloud Infrastructure (OCI):

        • OCI Logging: Use OCI Logging to manage and search logs, providing visibility into scaling events and their effects on system performance.

        • OCI Monitoring: Utilise OCI Monitoring to track metrics and set alarms, ensuring that scaling actions align with performance expectations.

    • By enhancing observability, you can validate the effectiveness of your autoscaling strategies, promptly identify and address issues, and optimise resource allocation to maintain application performance and cost efficiency.

  5. Adopt Spot/Preemptible Instances for Autoscaled Non-Critical Workloads

    • To further optimise costs, consider utilising spot or preemptible virtual machines (VMs) for non-critical, autoscaled workloads. These instances are offered at significant discounts compared to standard on-demand instances but can be terminated by the cloud provider when resources are needed elsewhere. Therefore, they are best suited for fault-tolerant and flexible applications.

      • AWS: Implement EC2 Spot Instances within an Auto Scaling Group to run fault-tolerant workloads at up to 90% off the On-Demand price. By configuring Auto Scaling groups with mixed instances, you can combine Spot Instances with On-Demand Instances to balance cost and availability.

      • Azure: Utilise Azure Spot Virtual Machines within Virtual Machine Scale Sets for non-critical workloads. Azure Spot VMs allow you to take advantage of unused capacity at significant cost savings, making them ideal for interruptible workloads such as batch processing jobs and development/testing environments.

      • Google Cloud Platform (GCP): Deploy Preemptible VMs in Managed Instance Groups to run short-duration, fault-tolerant workloads at a reduced cost. Preemptible VMs provide substantial savings for workloads that can tolerate interruptions, such as data analysis and batch processing tasks.

      • Oracle Cloud Infrastructure (OCI): Leverage Preemptible Instances for batch processing or flexible tasks. OCI Preemptible Instances offer a cost-effective solution for workloads that are resilient to interruptions, enabling efficient scaling of non-critical applications.

    • By integrating these cost-effective instance types into your autoscaling strategies, you can significantly reduce expenses for non-critical workloads while maintaining the flexibility to scale resources as needed.

By broadening autoscaling across more components, incorporating richer metrics, scheduling, and advanced cost strategies like spot instances, you transform your “basic” scaling approach into a more agile, cost-effective solution. Over time, these steps foster robust, automated resource management across your entire environment.

Widespread Autoscaling with Basic Metrics: Autoscaling is a common practice, although it mainly utilises basic metrics, with limited use of log or application-specific metrics.

How to determine if this good enough

You’ve expanded autoscaling across many workloads: from front-end services to internal APIs, possibly including some data processing components. However, you’re mostly using CPU, memory, or standard throughput metrics as triggers. This can be “good enough” if:

  1. Comprehensive Coverage

    • Most of your core applications scale automatically as demand changes. Manual interventions are rare and usually revolve around unusual events or big product launches.

  2. Efficient Day-to-Day Operations

    • Cost and capacity usage are largely optimised since few resources remain significantly underutilised or idle.
    • Staff seldom worry about reconfiguring capacity for typical fluctuations.

  3. Satisfactory Performance

    • Using basic metrics (CPU, memory) covers typical load patterns adequately.
    • The risk of slower scale-up in more complex scenarios (like surges in queue lengths or specific user transactions) might be acceptable.

  4. Stable or Predictable Load Growth

    • Even with widespread autoscaling, if your usage grows in somewhat predictable increments, basic triggers might suffice.
    • You rarely need to investigate advanced logs or correlation with end-user response times to refine scaling.

If your service-level objectives (SLOs) and budgets remain met with these simpler triggers, you may be comfortable. However, more advanced autoscaling can yield better responsiveness for spiky or complex applications that rely heavily on queue lengths, user concurrency, or custom application metrics (e.g., transactions per second, memory leaks, etc.).

How to do better

Here are actionable ways to refine your widespread autoscaling strategy to handle more nuanced workloads:

  1. Adopt Application-Level or Log-Based Metrics

    • Move beyond CPU and memory metrics to incorporate transaction rates, request latency, or user concurrency for more responsive and efficient autoscaling:

      • AWS:

        • CloudWatch Custom Metrics: Publish custom metrics derived from application logs to Amazon CloudWatch, enabling monitoring of specific application-level indicators such as transaction rates and user concurrency.
        • Real-Time Log Analysis with Kinesis and Lambda: Set up real-time log analysis by streaming logs through Amazon Kinesis and processing them with AWS Lambda to generate dynamic scaling triggers based on application behavior.

      • Azure:

        • Application Insights: Utilise Azure Monitor’s Application Insights to collect detailed usage data, including request rates and response times, which can inform scaling decisions for services hosted in Azure Kubernetes Service (AKS) or Virtual Machine Scale Sets.
        • Custom Logs for Scaling Signals: Implement custom logging to capture specific application metrics and configure Azure Monitor to use these logs as signals for autoscaling, enhancing responsiveness to real-time application demands.

      • Google Cloud Platform (GCP):

        • Cloud Monitoring Custom Metrics: Create custom metrics in Google Cloud’s Monitoring to track application-specific indicators such as request count, latency, or queue depth, facilitating more precise autoscaling of Compute Engine (GCE) instances or Google Kubernetes Engine (GKE) clusters.
        • Integration with Logging: Combine Cloud Logging with Cloud Monitoring to analyze application logs and derive metrics that can trigger autoscaling events based on real-time application performance.

      • Oracle Cloud Infrastructure (OCI):

        • Monitoring Custom Metrics: Leverage OCI Monitoring to create custom metrics from application logs, capturing detailed performance indicators that can inform autoscaling decisions.
        • Logging Analytics: Use OCI Logging Analytics to process and analyze application logs, extracting metrics that reflect user concurrency or transaction rates, which can then be used to trigger autoscaling events.

    • Incorporating application-level and log-based metrics into your autoscaling strategy allows for more nuanced and effective scaling decisions, ensuring that resources align closely with actual application demands and improving overall performance and cost efficiency.

  2. Introduce Multi-Metric Policies

    • Instead of a single threshold, combine metrics. For instance:
      • Scale up if CPU > 70% AND average request latency > 300ms.
      • This ensures you only scale when both resource utilisation and user experience degrade, reducing false positives or unneeded expansions.

  3. Implement Predictive or Machine Learning–Driven Autoscaling

    • To anticipate demand spikes before traditional metrics like CPU utilisation react, consider implementing predictive or machine learning–driven autoscaling solutions offered by cloud providers:

      • AWS:

      • Azure:

        • Predictive Autoscale: Utilise Predictive Autoscale in Azure Monitor, which employs machine learning to forecast CPU load for Virtual Machine Scale Sets based on historical usage patterns, enabling proactive scaling.

      • Google Cloud Platform (GCP):

        • Custom Machine Learning Models: Develop custom machine learning models to analyze historical performance data and predict future demand, triggering autoscaling events in services like Google Kubernetes Engine (GKE) or Cloud Run based on these forecasts.

      • Oracle Cloud Infrastructure (OCI):

        • Custom Analytics Integration: Integrate Oracle Analytics Cloud with OCI to perform machine learning–based forecasting, enabling predictive scaling by analyzing historical data and anticipating future resource requirements.

    • Implementing predictive or machine learning–driven autoscaling allows your applications to adjust resources proactively, maintaining performance and cost efficiency by anticipating demand before traditional metrics indicate the need for scaling.

  4. Correlate Autoscaling with End-User Experience

    • To enhance user satisfaction, align your autoscaling strategies with user-centric metrics such as page load times and overall responsiveness. By monitoring these metrics, you can ensure that scaling actions directly improve the end-user experience.

      • AWS:

        • Application Load Balancer (ALB) Target Response Times: Monitor ALB target response times using Amazon CloudWatch to assess backend performance. Elevated response times can indicate the need for scaling to maintain optimal user experience.
        • Network Load Balancer (NLB) Metrics: Track NLB metrics to monitor network performance and identify potential bottlenecks affecting end-user experience.

      • Azure:

        • Azure Front Door Logs: Analyze Azure Front Door logs to monitor end-to-end latency and other performance metrics. Insights from these logs can inform scaling decisions to enhance user experience.
        • Application Insights: Utilise Application Insights to collect detailed telemetry data, including response times and user interaction metrics, aiding in correlating autoscaling with user satisfaction.

      • Google Cloud Platform (GCP):

        • Cloud Load Balancing Logs: Examine Cloud Load Balancing logs to assess request latency and backend performance. Use this data to adjust autoscaling policies, ensuring they align with user experience goals.
        • Service Level Objectives (SLOs): Define SLOs in Cloud Monitoring to set performance targets based on user-centric metrics, enabling proactive scaling to meet user expectations.

      • Oracle Cloud Infrastructure (OCI):

        • Load Balancer Health Checks: Implement OCI Load Balancer health checks to monitor backend server performance. Use health check data to inform autoscaling decisions that directly impact user experience.
        • Custom Application Pings: Set up custom application pings to measure response times and user concurrency, feeding this data into autoscaling triggers to maintain optimal performance during varying user loads.

    • By integrating user-centric metrics into your autoscaling logic, you ensure that scaling actions are directly correlated with improvements in end-user experience, leading to higher satisfaction and engagement.

  5. Refine Scaling Cooldowns and Timers

    • Tweak scale-up and scale-down intervals to avoid thrashing:
      • A short scale-up delay can address spikes quickly.
      • A slightly longer scale-down delay prevents abrupt resource removals when a short spike recedes.
    • Evaluate your autoscaling policy settings monthly to align with evolving traffic patterns.

By incorporating more sophisticated application or log-based metrics, predictive scaling, and user-centric triggers, you ensure capacity aligns closely with real workloads. This approach elevates your autoscaling from a broad CPU/memory-based strategy to a finely tuned system that balances user experience, performance, and cost efficiency.

Advanced Autoscaling Using Detailed Metrics: Autoscaling is ubiquitously used, based on sophisticated log or application metrics, allowing for highly responsive and efficient capacity allocation.

How to determine if this good enough

In this final, most mature stage, your organisation applies advanced autoscaling across practically every production workload. Detailed logs, queue depths, user concurrency, or response times drive scaling decisions. This likely means:

  1. Holistic Observability and Telemetry

    • You collect and analyze logs, metrics, and traces in near real-time, correlating them to auto-scale events.
    • Teams have dashboards that reflect business-level metrics (e.g., transactions processed, citizen requests served) to trigger expansions or contractions.

  2. Proactive or Predictive Scaling

    • You anticipate traffic spikes based on historical data or usage trends (like major public announcements, election result postings, etc.).
    • Scale actions happen before a noticeable performance drop, offering a seamless user experience.

  3. Minimal Human Intervention

    • Manual resizing is rare, reserved for extraordinary circumstances (e.g., emergent security patches, new application deployments).
    • Staff focus on refining autoscaling policies, not reacting to capacity emergencies.

  4. Cost-Optimised and Performance-Savvy

    • Because you rarely over-provision for extended periods, your budget usage remains tightly aligned with actual needs.
    • End-users or citizens experience consistently fast response times due to prompt scale-outs.

If you find that your applications handle usage spikes gracefully, cost anomalies are rare, and advanced metrics keep everything stable, you have likely achieved an advanced autoscaling posture. Nevertheless, with the rapid evolution of cloud services, there are always methods to iterate and improve.

How to do better

Even at the top level, you can refine and push boundaries further:

  1. Adopt More Granular “Distributed SLO” Metrics

    • Evaluate Each Microservice’s Service-Level Objectives (SLOs): Define precise SLOs for each microservice, such as ensuring the 99th-percentile latency remains under 400 milliseconds. This granular approach allows for targeted performance monitoring and scaling decisions.

    • Utilise Cloud Provider Tools to Monitor and Enforce SLOs:

      • AWS:

        • CloudWatch ServiceLens: Integrate Amazon CloudWatch ServiceLens to gain comprehensive insights into application performance and availability, correlating metrics, logs, and traces.
        • Custom Metrics and SLO-Based Alerts: Implement custom CloudWatch metrics to monitor specific performance indicators and set up SLO-based alerts to proactively manage service health.

      • Azure:

        • Application Insights: Leverage Azure Monitor’s Application Insights to track detailed telemetry data, enabling the definition and monitoring of SLOs for individual microservices.
        • Service Map: Use Azure Monitor’s Service Map to visualise dependencies and performance metrics across services, aiding in the assessment of SLO adherence.

      • Google Cloud Platform (GCP):

        • Cloud Operations Suite: Employ Google Cloud’s Operations Suite to create SLO dashboards that monitor service performance against defined objectives, facilitating informed scaling decisions.

      • Oracle Cloud Infrastructure (OCI):

        • Observability and Management Platform: Implement OCI’s observability tools to define SLOs and correlate them with performance metrics, ensuring each microservice meets its performance targets.

    • Benefits of Implementing Distributed SLO Metrics:

      • Precision in Scaling: By closely monitoring how each component meets its SLOs, you can make informed decisions to scale resources appropriately, balancing performance needs with cost considerations.

      • Proactive Issue Detection: Granular SLO metrics enable the early detection of performance degradations within specific microservices, allowing for timely interventions before they impact the overall system.

      • Enhanced User Experience: Maintaining stringent SLOs ensures that end-users receive consistent and reliable service, thereby improving satisfaction and trust in your application.

    • Implementation Considerations:

      • Define Clear SLOs: Collaborate with stakeholders to establish realistic and measurable SLOs for each microservice, considering factors such as latency, throughput, and error rates.

      • Continuous Monitoring and Adjustment: Regularly review and adjust SLOs and associated monitoring tools to adapt to evolving application requirements and user expectations.

    • Conclusion: Adopting more granular “distributed SLO” metrics empowers you to fine-tune your application’s performance management, ensuring that each microservice operates within its defined parameters. This approach facilitates precise scaling decisions, optimising both performance and cost efficiency.

  2. Experiment with Multi-Provider or Hybrid Autoscaling

  3. Integrate with Detailed Cost Allocation & Forecasting

  4. Leverage AI/ML for Real-Time Scaling Decisions

  5. Adopt Sustainable/Green Autoscaling Policies

By blending advanced SLO-based scaling, multi-provider strategies, cost forecasting, ML-driven anomaly detection, and sustainability considerations, you ensure your autoscaling remains cutting-edge. This not only provides exemplary performance and cost control but also positions your UK public sector organisation as a leader in efficient, responsible cloud computing.

Keep doing what you’re doing, and consider sharing your successes via blog posts or internal knowledge bases. Submit pull requests to this guidance if you have innovative approaches or examples that can benefit other public sector organisations. By exchanging real-world insights, we collectively raise the bar for cloud maturity and cost effectiveness across the entire UK public sector.

How does your organisation approach the use of compute services in the cloud?

Long-Running Homogeneous VMs: Workloads are consistently deployed on long-running, homogeneously sized Virtual Machines (VMs), without variation or optimisation.

How to determine if this good enough

An organisation that relies on “Long-Running Homogeneous VMs” typically has static infrastructure: they stand up certain VM sizes—often chosen arbitrarily or based on outdated assumptions—and let them run continuously. For a UK public sector body, this may appear straightforward if:

  1. Predictable, Low-Complexity Workloads

    • Your compute usage doesn’t fluctuate much (e.g., a small number of internal line-of-business apps with stable user counts).
    • You don’t foresee major surges or dips in demand.
    • The overhead of changing compute sizes or rearchitecting to dynamic services might seem unnecessary.

  2. Minimal Cost Pressures

    • If your monthly spend is low enough to be tolerated within your departmental budget or you lack strong impetus from finance to optimise further.
    • You might feel that it’s “not broken, so no need to fix it.”

  3. Legacy Constraints

    • Some local authority or government departments could be running older applications that are hard to containerise or re-platform. If you require certain OS versions or on-prem-like architectures, homogeneous VMs can seem “safe.”

  4. Limited Technical Skills or Resources

    • You may not have in-house expertise to manage containers, function-based services, or advanced orchestrators.
    • If your main objective is stability and you have no immediate impetus to experiment, you might remain with static VM setups.

If you fall into these categories—low complexity, legacy constraints, stable usage, minimal cost concerns—then “Long-Running Homogeneous VMs” might indeed be “good enough.” However, many UK public sector cloud strategies now emphasize cost efficiency, scalability, and elasticity, especially under increased scrutiny of budgets and service reliability. Sticking to homogeneous, always-on VMs without optimisation can lead to wasteful spending, hamper agility, and prevent future readiness.

How to do better

Here are rapidly actionable improvements to help you move beyond purely static VMs:

  1. Enable Basic Monitoring and Cost Insights

  2. Leverage Built-in Right-sizing Tools

  3. Introduce Simple Scheduling

  4. Conduct a Feasibility Check for a Small Container Pilot

  5. Raise Awareness with Internal Stakeholders

    • Share simple usage and cost graphs with your finance or leadership teams. Show them the difference between “always-on” vs. “scaled” or “scheduled” usage.
    • This could drive more formal mandates or budget incentives to encourage partial re-architecture or adoption of short-lived compute in the future.

By monitoring usage, applying right-sizing, scheduling idle time, and introducing a small container pilot, you can meaningfully reduce waste. Over time, you’ll build momentum toward more flexible compute strategies while still respecting the constraints of your existing environment.

Primarily Long-Running VMs with Limited Experimentation: Most workloads are on long-running VMs, with some limited experimentation in containers or function-based services for non-critical tasks.

How to determine if this good enough

Organisations in this stage have recognised the benefits of more dynamic compute models—like containers or serverless—but apply them only in a small subset of cases. You might be “good enough” if:

  1. Core Workloads Still Suited to Static VMs

    • Perhaps your main applications are large, monolithic solutions that can’t easily shift to containers or functions.
    • The complexity of re-platforming may outweigh the immediate gains.

  2. Selective Use of Modern Compute

    • You have tested container-based or function-based solutions for simpler tasks (e.g., cron jobs, internal scheduled data processing, or small web endpoints).
    • The results are encouraging, but you haven’t had the internal capacity or business priority to expand further.

  3. Comfortable Cost Baseline

    • You’ve introduced auto-shutdown or partial right-sizing for your VMs, so your costs are not spiraling.
    • Leadership sees no urgent impetus to push deeper into containers or serverless, perhaps because budgets remain stable or there’s no urgent performance/elasticity requirement.

  4. Growing Awareness of Container or Serverless Advantages

    • Some staff or teams are championing more frequent usage of advanced compute.
    • The IT department sees potential, but organisational inertia, compliance considerations, or skill gaps limit widespread adoption.

If the majority of your mission-critical applications remain on VMs and you see stable performance within budget, this may be “enough” for now. However, if the cloud usage is expanding, or if your department is under pressure to modernise, you might quickly find you miss out on elasticity, cost efficiency, or resilience advantages that come from broader container or serverless adoption.

How to do better

Here are actionable next steps to accelerate your modernisation journey without overwhelming resources:

  1. Expand Container/Serverless Pilots in a Structured Way

  2. Implement Granular VM Auto-Scaling

  3. Use Container Services for Non-Critical Production

    • If you have a stable container proof-of-concept, consider migrating a small but genuine production workload. Examples:
      • Internal APIs, internal data analytics pipelines, or front-end servers that can scale up/down.
      • Focus on microservices that do not require extensive refactoring.
    • This fosters real operational experience, bridging from “non-critical tasks” to “production readiness.”

  4. Leverage Cloud Marketplace or Government Frameworks

    • Explore container-based solutions or DevOps tooling that might be available under G-Cloud or Crown Commercial Service frameworks.
    • Some providers offer managed container solutions pre-configured for compliance or security—this can reduce friction around governance.

  5. Train or Upskill Teams

    Building confidence and skills helps teams adopt more advanced compute models.

Through these steps—structured expansions of containerised or serverless pilots, improved auto-scaling of VMs, and staff training—your organisation can gradually shift from “limited experimentation” to a more balanced compute ecosystem. The result is improved agility, potential cost savings, and readiness for more modern architectures.

Mixed Use with Some Advanced Compute Options: Some production workloads are run in containers or function-based compute services. Ad-hoc use of short-lived VMs is practiced, with efforts to right-size based on workload needs.

How to determine if this good enough

This stage indicates a notable transformation: your organisation uses multiple compute paradigms. You have container-based or serverless workloads in production, you sometimes spin up short-lived VMs for ephemeral tasks, and you’re actively right-sizing. It may be “good enough” if:

  1. Functional, Multi-Modal Compute Strategy

    • You’ve proven that containers or serverless can handle real production demands (e.g., public-facing services, departmental applications).
    • VMs remain important for some workloads, but you adapt or re-size them more frequently.

  2. Solid Operational Knowledge

    • Your teams are comfortable deploying to a container platform (e.g., Kubernetes, ECS, Azure WebApps for containers, etc.) or using function-based services in daily workflows.
    • Monitoring and alerting are configured for both ephemeral and long-running compute.

  3. Balanced Cost and Complexity

    • You have a handle on typical monthly spend, and finance sees a correlation between usage spikes and cost.
    • You might not be fully optimising everything, but you rarely see large, unexplained bills.

  4. Clear Upsides from Modern Compute

    • You’ve recognised that certain microservices perform better or cost less on serverless or containers.
    • Cultural buy-in is growing: multiple teams express interest in flexible compute models.

If these points match your environment, your “Mixed Use” approach might currently satisfy your user needs and budget constraints. However, you might still see opportunities to refine deployment methods, unify your management or monitoring, and push for greater elasticity. If you suspect further cost savings or performance gains are possible—or you want a more standardised approach across the organisation—further advancement is likely beneficial.

How to do better

Below are rapidly actionable ways to enhance your mixed compute model:

  1. Adopt Unified Deployment Pipelines

    • Strive for standard tooling that can deploy both VMs and container/serverless environments. For instance:
    • This reduces fragmentation and fosters consistent best practices (code review, automated testing, environment provisioning).

  2. Enhance Observability

  3. Introduce a Tagging/Governance Policy

  4. Implement Automated or Dynamic Scaling

    Implementing these scaling strategies ensures that your applications can efficiently handle varying workloads while controlling costs.

  5. Leverage Reserved or Discounted Pricing for Steady Components

    Implementing these strategies can lead to significant cost savings for workloads with consistent usage patterns.

By unifying your deployment practices, consolidating observability, enforcing tagging, and refining autoscaling or discount usage, you move from an ad-hoc mix of compute styles to a more cohesive, cost-effective cloud ecosystem. This sets the stage for robust, consistent governance and significant agility gains.

Regular Use of Short-Lived VMs and Containers: There is regular use of short-lived VMs and containers, along with some function-based compute services. This indicates a move towards more flexible and scalable compute options.

How to determine if this good enough

When your organisation regularly uses ephemeral or short-lived compute models, containers, and functions, you’ve likely embraced cloud-native thinking. This suggests:

  1. Frequent Scaling and Automated Lifecycle

    • You seldom keep large VMs running 24/7 unless absolutely necessary.
    • Container-based architectures or ephemeral VMs scale up to meet demand, then terminate when idle.

  2. High Automation in CI/CD

    • Deployments to containers or serverless happen automatically via pipelines.
    • Infrastructure provisioning is likely codified in IaC (Infrastructure as Code) tooling (Terraform, CloudFormation, Bicep, etc.).

  3. Performance and Cost Efficiency

    • You typically pay only for what you use, cutting down on waste.
    • Application performance can match demand surges without manual intervention.

  4. Multi-Service Observability

    • Monitoring covers ephemeral workloads, with logs and metrics aggregated effectively.

If you have reached this point, your environment is more agile, cost-optimised, and aligned with modern DevOps. However, you may still have gaps in advanced scheduling, deeper security or compliance integration, or a formal approach to evaluating each new solution (e.g., deciding between containers, serverless, or a managed SaaS).

How to do better

Below are actionable expansions to push your ephemeral usage approach further:

  1. Adopt a “Compute Decision Framework”

    • Formalise how new workloads choose among FaaS (functions), CaaS (containers), or short-lived VMs:
      • If event-driven with spiky traffic, prefer serverless.
      • If the service requires consistent runtime dependencies but can scale, prefer containers.
      • If specialised hardware or older OS is needed briefly, use short-lived VMs.
    • This standardisation helps teams quickly pick the best fit.

  2. Enable Event-Driven Automation

  3. Implement Container Security Best Practices

  4. Refine Infrastructure as Code (IaC) and Pipeline Patterns

  5. Extend Tagging and Cost Allocation

By formalising your decision framework, expanding event-driven architectures, ensuring container security, and strengthening IaC patterns, you solidify your short-lived compute model. This approach reduces overheads, fosters agility, and helps UK public sector teams remain compliant with cost and operational excellence targets.

‘Fit for Purpose’ Approach with Rigorous Right-sizing: Cloud services selection is driven by a strict ‘fit for purpose’ approach. This includes a rigorous continual right-sizing process and a solution evaluation hierarchy favoring SaaS > FaaS > Containers as a Service > Platform/Orchestrator as a Service > Infrastructure as a Service.

How to determine if this good enough

At this highest maturity level, you explicitly choose the most appropriate computing model—often starting from SaaS (Software as a Service) if it meets requirements, then serverless if custom code is needed, then containers, and so on down to raw VMs only when necessary. Indicators that this might be “good enough” include:

  1. Every New Project Undergoes a Thorough Fit Assessment

    • Your solution architecture process systematically asks: “Could an existing SaaS platform solve this? If not, can serverless do the job? If not, do we need container orchestration?” and so forth.
    • This approach prevents defaulting to IaaS or large container clusters without strong justification.

  2. Rigorous Continual Right-sizing

    • Teams actively measure usage and adjust resource allocations monthly or even weekly.
    • Underutilised resources are quickly scaled down or replaced by ephemeral compute. Over-stressed services are scaled up or moved to more robust solutions.

  3. Sophisticated Observability, Security, and Compliance

    • With multiple service layers, you maintain consistent monitoring, security scanning, and compliance checks across SaaS, FaaS, containers, and IaaS.
    • You have well-documented runbooks and automated pipelines to handle each technology layer.

  4. Cost Efficiency and Agility

    • Budgets often reflect usage-based spending, and spikes are quickly noticed.
    • Development cycles are faster because you adopt higher-level services first, focusing on business logic rather than infrastructure management.

If your organisation can demonstrate that each new or existing application sits in the best-suited compute model—balancing cost, compliance, and performance—this is typically considered the pinnacle of cloud compute maturity. However, continuous improvements in vendor offerings, emerging technologies, and changing departmental requirements mean there is always more to refine.

How to do better

Even at this advanced state, you can still hone practices. Below are suggestions:

  1. Automate Decision Workflows

    • Build an internal “Service Catalog” or “Decision Tree.” For instance:
      • A web-based form that asks about the workload’s functional, regulatory, performance, and cost constraints, then suggests suitable solutions (SaaS, FaaS, containers, etc.).
    • This can be integrated with pipeline automation so new projects must pass through the framework before provisioning resources.

  2. Deepen SaaS Exploration for Niche Needs

    • Explore specialised SaaS options for areas like data analytics, content management, or identity services.
    • Ensure your staff or solution architects regularly revisit the G-Cloud listings or other Crown Commercial Service frameworks to see if an updated SaaS solution can replace custom-coded or container-based systems.

  3. Further Standardise DevOps Across All Layers

  4. Maintain a Living Right-sizing Strategy

  5. Focus on Energy Efficiency and Sustainability

  6. Champion Cross-Public-Sector Collaboration

    • Share lessons or templates with other departments or agencies. This fosters consistent best practices across local councils, NHS trusts, or central government bodies.

By automating your decision workflows, continuously exploring SaaS, standardising DevOps pipelines, and incorporating advanced metrics (including sustainability), you maintain an iterative improvement path at the peak of compute maturity. This ensures you remain agile in responding to new user requirements and evolving government initiatives, all while controlling costs and optimising resource efficiency.

Keep doing what you’re doing, and consider writing up success stories, internal case studies, or blog posts. Submit pull requests to this guidance or relevant public sector best-practice repositories so others can learn from your achievements. By sharing real-world experiences, you help the entire UK public sector enhance its cloud compute maturity.

How does your organisation plan, measure, and optimise the environmental sustainability and carbon footprint of its cloud compute resources?

Basic Vendor Reliance: Sustainability isn’t actively measured internally; reliance is placed on cloud vendors who are contractually obligated to work towards carbon neutrality, likely through offsetting.

How to determine if this good enough

In this stage, your organisation trusts its cloud provider to meet green commitments through mechanisms like carbon offsetting or renewable energy purchases. You likely have little to no visibility of actual carbon metrics. For UK public sector bodies, you might find this acceptable if:

  1. Limited Scope and Minimal Usage
    • Your cloud footprint is extremely small (e.g., a handful of testing environments).
    • The cost and complexity of internal measurement may not seem justified at this scale.
  2. No Immediate Policy or Compliance Pressures
    • You face no urgent departmental or legislative requirement to detail your carbon footprint.
    • Senior leadership may not yet be asking for sustainability reports.
  3. Strong Confidence in Vendor Pledges
    • Your contract or statements of work (SoW) reassure you that the provider is pursuing net zero or carbon neutrality.
    • You have no immediate impetus to verify or go deeper into the supply chain or usage details.

If you are in this situation and operate with minimal complexity, “Basic Vendor Reliance” might be temporarily “good enough.” However, the UK public sector is increasingly required to evidence sustainability efforts, particularly under initiatives like the Greening Government Commitments. Larger or rapidly growing workloads will likely outgrow this approach. If you anticipate expansions, cost concerns, or scrutiny from oversight bodies, it is wise to move beyond vendor reliance.

How to do better

Below are rapidly actionable steps that provide greater visibility and ensure you move beyond mere vendor assurances:

  1. Request Vendor Transparency

  2. Enable Basic Billing and Usage Reports

  3. Incorporate Sustainability Clauses in Contracts

    • When renewing or issuing new calls on frameworks like G-Cloud, add explicit language for carbon reporting.
    • Request quarterly or annual updates on how your usage ties into the vendor’s net-zero or carbon offset strategies.

    Incorporating sustainability clauses into your contracts is essential for ensuring that your cloud service providers align with your environmental goals. The Crown Commercial Service offers guidance on integrating such clauses into the G-Cloud framework. Additionally, the Chancery Lane Project provides model clauses for environmental performance, which can be adapted to your contracts.

    By proactively including these clauses, you can hold vendors accountable for their sustainability commitments and ensure that your organisation’s operations contribute positively to environmental objectives.

  4. Track Internal Workload Growth

    • Even if you rely on vendor neutrality claims, set up a simple spreadsheet or a lightweight tracker for each of your main cloud workloads (service name, region, typical CPU usage, typical memory usage). If usage grows, you will notice potential new carbon hotspots.

  5. Raise Internal Awareness

    • Create a short briefing note for leadership or relevant teams (e.g., finance, procurement) highlighting:
      1. Your current reliance on vendor offsetting, and
      2. The need for baseline data collection.

    This ensures any interest in deeper environmental reporting can gather support before usage grows further.

Initial Awareness and Basic Policies: Some basic policies and goals for sustainability are set. Efforts are primarily focused on awareness and selecting vendors with better environmental records.

How to determine if this good enough

At this stage, you have moved beyond “vendor says they’re green.” You may have a written policy stating that you will prioritise environmentally responsible suppliers or aim to reduce your cloud emissions. For UK public sector organisations, “Initial Awareness” may be adequate if:

  1. Formal Policy Exists, but Execution Is Minimal

    • You have a documented pledge or departmental instruction to pick greener vendors or to reduce carbon, but it’s largely aspirational.

  2. Some Basic Tracking or Guidance

    • Procurement teams might refer to environmental credentials during tendering, especially if you’re using Crown Commercial Service frameworks.
    • Staff are aware that sustainability is important, but lack practical steps.

  3. Minimal External Oversight

    • You might not yet be required to publish detailed carbon metrics in annual reports or meet stringent net zero timelines.
    • The policy helps reduce reputational risk, but you have not turned it into tangible workflows.

This approach is a step up from total vendor reliance. However, it often lacks robust measurement or accountability. If your workload, budget, or public scrutiny around environmental impact is increasing—particularly in line with the Greening Government Commitments you will likely need more rigorous strategies soon.

How to do better

Here are quick wins to strengthen your approach and make it more actionable:

  1. Use Vendor Sustainability Tools for Basic Estimation

  2. Create Simple Internal Guidelines

    • Expand beyond policy statements:
      1. Resource Tagging: Mandate that every new resource is tagged with an owner, environment, and a sustainability tag (e.g., “non-prod, auto-shutdown” vs. “production, high-availability”).
      2. Preferred Regions: If feasible, prefer data centers that the vendor identifies as more carbon-friendly. For example, some AWS and Azure UK-based regions rely on greener energy sourcing than others.

  3. Schedule Simple Sustainability Checkpoints

    • Alongside your standard procurement or architectural reviews, add a sustainability review item. E.g.:
      • “Does the new service use the recommended low-carbon region?”
      • “Is there a plan to power down dev/test resources after hours?”
    • This ensures your new policy is not forgotten in day-to-day activities.

  4. Offer Quick Training or Knowledge Sessions

    The point is to connect cost optimisation with sustainability—over-provisioned resources burn more carbon.

  5. Publish Simple Reporting

    • Create a once-a-quarter dashboard or presentation highlighting approximate cloud emissions. Even if the data is partial or not perfect, transparency drives accountability.

By rapidly applying these steps—using native vendor tools to measure usage, establishing minimal but meaningful guidelines, and scheduling brief training or check-ins—you elevate your policy from mere awareness to actual practice.

Active Measurement and Target Setting: The organisation actively measures its cloud compute carbon footprint and sets specific targets for reduction. This includes choosing cloud services based on their sustainability metrics.

How to determine if this good enough

Here, you have begun quantifying your cloud-based carbon output. You might set yearly or quarterly reduction goals (e.g., a 10% decrease in carbon from last year). You also factor environmental impacts into your choice of instance types, storage classes, or regions. Signs this might be “good enough” include:

  1. Regular Carbon Footprint Data

    • You have monthly or quarterly reports from vendor dashboards or a consolidated internal system (e.g., pulling data from cost/billing APIs plus vendor carbon intensity metrics).

  2. Formal Targets and Milestones

    • Leadership acknowledges these targets. They appear in your departmental objectives or technology strategy.

  3. Procurement Reflects Sustainability

    • RFQs or tenders explicitly weigh sustainability factors, awarding points to vendors or proposals that commit to lower carbon usage.
    • You might require prospective suppliers to share energy efficiency data for their services.

  4. Leadership or External Bodies Approve

    • Senior managers or oversight bodies see your target-setting approach as credible.
    • Your reports are used in annual reviews or compliance documentation.

While “Active Measurement and Target Setting” is a robust step forward, you may still discover that your usage continues to increase due to scaling demands or new digital services. Additionally, you might lack advanced optimisation practices like continuous resource right-sizing or dynamic load shifting.

How to do better

Focus on rapid, vendor-native steps to convert targets into tangible reductions:

  1. Automate Right-sizing

    By automatically resizing or shifting to lower-tier SKUs, you reduce both cost and emissions.

  2. Implement Scheduled Autoscaling

    This directly lowers carbon usage by removing idle capacity.

  3. Leverage Serverless or Container Services

    Serverless can significantly cut wasted resources, which aligns with your reduction targets.

  4. Adopt “Carbon Budgets” in Project Plans

These tools provide insights into the carbon emissions associated with different regions, enabling more sustainable decision-making.

  1. Align with Departmental or National Sustainability Goals
    • Update your internal reporting to reflect how your targets link to national net zero obligations or departmental commitments (e.g., the NHS net zero plan, local authority climate emergency pledges). This ensures your measurement and goals remain relevant to broader public sector accountability.

Implementing these steps swiftly helps ensure you don’t just measure but actually reduce your carbon footprint. Regular iteration—checking usage data, right-sizing, adjusting autoscaling—ensures continuous progress toward your stated targets.

Integrated Sustainability Practices: Sustainability is integrated into cloud resource planning and usage. This includes regular monitoring and reporting on sustainability metrics and making adjustments to improve environmental impact.

How to determine if this good enough

At this stage, sustainability isn’t a separate afterthought—it’s part of your default operational processes. Indications that you might be “good enough” for UK public sector standards include:

  1. Frequent/Automated Monitoring

    • Carbon metrics are tracked at least weekly, if not daily, using integrated dashboards.
    • You have alerts for unexpected surges in usage or carbon-intense resources.

  2. Cultural Adoption Across Teams

    • DevOps, procurement, and governance leads all know how to incorporate sustainability criteria.
    • Architects regularly consult carbon metrics during design sessions, akin to how they weigh cost or security.

  3. Regular Public or Internal Reporting

    • You might publish simplified carbon reports in your annual statements or internally for senior leadership.
    • Stakeholders can see monthly/quarterly improvements, reflecting a stable, integrated practice.

  4. Mapping to Strategic Objectives

    • The departmental net zero or climate strategy references your integrated approach as a key success factor.
    • You can demonstrate tangible synergy: e.g., your cost savings from scaling down dev environments are also cutting carbon.

Despite these achievements, additional gains can still be made, especially in advanced workload scheduling or region selection. If you want to stay ahead of new G-Cloud requirements, carbon scoring frameworks, or stricter net zero mandates, you may continue optimising your environment.

How to do better

Actionable steps to deepen your integrated approach:

  1. Set Up Automated Governance Rules

Implementing these policies ensures that resources are deployed in regions with lower carbon footprints, aligning with your sustainability objectives.

  1. Adopt Full Lifecycle Management

  2. Use Vendor-Specific Sustainability Advisors

    Incorporate these suggestions directly into sprint backlogs or monthly improvement tasks.

  3. Embed Sustainability in DevOps Pipelines

    • Modify build/deployment pipelines to check resource usage or region selection:
      • If a new environment is spun up in a high-carbon region or with large instance sizes, the pipeline can prompt a warning or require an override.
      • Tools like GitHub Actions or Azure DevOps Pipelines can call vendor APIs to fetch sustainability metrics and fail a build if it’s non-compliant.

  4. Promote Cross-Functional “Green Teams”

    • Form a small working group or “green champions” network across procurement, DevOps, governance, and finance, meeting monthly to share best practices and track new optimisation opportunities.
    • This approach keeps your integrated practices dynamic, ensuring you respond quickly to new vendor features or updated government climate guidance.

By adding these automated controls, pipeline checks, and cross-functional alignment, you ensure that your integrated sustainability approach not only continues but evolves in real time. You become more agile in responding to shifting requirements and new tools, maintaining a leadership stance in UK public sector cloud sustainability.

Advanced Optimisation and Dynamic Management: Advanced strategies are in place, like automatic time and location shifting of workloads to minimise impact. Data retention and cloud product selection are deeply aligned with sustainability goals and carbon footprint metrics.

How to determine if this good enough

At the pinnacle of cloud sustainability maturity, your organisation leverages sophisticated methods such as:

  1. Real-Time or Near-Real-Time Workload Scheduling

    • When feasible and compliant with data sovereignty, you shift workloads to times/locations with lower carbon intensity.
    • You may monitor the UK grid’s real-time carbon intensity and schedule large batch jobs during off-peak, greener times.

  2. Full Lifecycle Carbon Costing

    • Every service or data set has an associated “carbon cost,” influencing decisions from creation to archival/deletion.
    • You constantly refine how your application code runs to reduce unnecessary CPU cycles, memory usage, or data transfers.

  3. Continuous Improvement Culture

    • Teams treat carbon optimisation as essential as cost or performance. Even minor improvements (e.g., 2% weekly CPU usage reduction) are celebrated.

  4. Cross-Government Collaboration

    • As a leader, you might share advanced scheduling or dynamic region selection techniques with other public sector bodies.
    • You might co-publish guidance for G-Cloud or Crown Commercial Service frameworks on advanced sustainability requirements.

If you have truly dynamic optimisation but remain within the constraints of UK data protection or performance needs, you have likely achieved a highly advanced state. However, there’s almost always room to push boundaries, such as exploring new hardware (e.g., ARM-based servers) or adopting emergent best practices in green software engineering.

How to do better

Even at this advanced level, below are further actions to refine your dynamic management:

  1. Build or Leverage Carbon-Aware Autoscaling

  2. Collaborate with BEIS or Relevant Government Bodies

    • The Department for Business, Energy & Industrial Strategy (BEIS) or other departments may track grid-level carbon. If you can integrate their public data (e.g., real-time carbon intensity in the UK), you can refine your scheduling.
    • Seek synergy with national digital transformation or sustainability pilot programmes that might offer new tools or funding for experimentation.

  3. AI or ML-Driven Forecasting

    Then automatically shift or throttle workloads accordingly.

  4. Innovate with Low-Power Hardware

    Typically, these instance families consume less energy for similar workloads, further reducing carbon footprints.

  5. Automated Data Classification and Tiering

    This ensures minimal energy overhead for data retention.

  6. Set an Example through Openness

    • If compliance allows, publish near real-time dashboards illustrating your advanced scheduling successes or hardware usage.
    • Share code or Infrastructure-as-Code templates with other public sector teams to accelerate mutual learning.

By implementing these advanced tactics, you sharpen your dynamic optimisation approach, continuously pushing the envelope of what’s possible in sustainable cloud operations—while respecting legal constraints around data sovereignty and any performance requirements unique to public services.

Keep doing what you’re doing, and consider documenting or blogging about your experiences. Submit pull requests to this guidance so other UK public sector organisations can accelerate their own sustainability journeys. By sharing real-world results and vendor-specific approaches, you help shape a greener future for public services across the entire nation.

What approaches does your organisation use to plan, measure, and optimise cloud spending?

Restricted Billing Visibility: Billing details are only accessible to management and finance teams, with limited transparency across the organisation.

How to determine if this good enough

Restricted Billing Visibility typically implies that your cloud cost data—such as monthly bills, usage breakdowns, or detailed cost analytics—remains siloed within a small subset of individuals or departments, usually finance or executive leadership. This might initially appear acceptable if you believe cost decisions do not directly involve engineering teams, product owners, or other stakeholders. It can also seem adequate when your organisation is small, or budgets are centrally controlled. However, carefully assessing whether this arrangement still meets your current and emerging needs requires a closer look at multiple dimensions: stakeholder awareness, accountability for financial outcomes, cross-functional collaboration, and organisational growth.

  1. Stakeholder Awareness and Alignment

    • When only a narrow group (e.g., finance managers) knows the full cost details, other stakeholders may make decisions in isolation, unaware of the larger financial implications. This can lead to inflated resource provisioning, missed savings opportunities, or unexpected billing surprises.
    • Minimal cost visibility might still be sufficient if your organisation’s usage is predictable, your budget is stable, and your infrastructure is relatively small. In such scenarios, cost control may not be a pressing concern. Nevertheless, even in stable environments, ignoring cost transparency could result in incremental increases that go unnoticed until they become significant.

  2. Accountability for Financial Outcomes

    • Finance teams that are solely responsible for paying the bill and analyzing cost trends might not have enough granular knowledge of the engineering decisions driving those costs. If your developers or DevOps teams are not looped in, they cannot easily optimise code, infrastructure, or architecture to reduce waste.
    • This arrangement can be considered “good enough” if your service-level agreements demand minimal overhead from engineers, or if your leadership structure is comfortable with top-down cost directives. However, the question remains: are you confident that your engineering teams have no role to play in optimising usage patterns? If the answer is that engineers do not need to see cost data to be efficient, you might remain in this stage without immediate issues. But typically, as soon as your environment grows in complexity, the limitation becomes evident.

  3. Cross-Functional Collaboration

    • Siloed billing data hinders cross-functional input and collaboration. Product managers, engineering leads, and operational teams may not easily communicate about the cost trade-offs associated with new features, expansions, or refactoring.
    • This might be “good enough” if your operating model is highly centralised and decisions about capacity, performance, or service expansion are made primarily through a few financial gatekeepers. Yet, even in such a centralised model, growth or changing business goals frequently demand more nimble, collaborative approaches.

  4. Scalability Concerns and Future Growth

    • When usage scales or new product lines are introduced, a lack of broader cost awareness can quickly escalate monthly bills. If your environment remains small or has limited growth, you might not face immediate cost explosions.
    • However, any potential business pivot—such as adopting new cloud services, launching in additional regions, or implementing a continuous delivery model—might cause your costs to spike in ways that a small finance-only group cannot effectively preempt.

  5. Risk Assessment

    • A direct risk in “Restricted Billing Visibility” is the possibility of accumulating unnecessary spend because the people who can make technical changes (engineers, developers, or DevOps) do not have the insight to detect cost anomalies or scale down resources.
    • If your usage remains modest and you have a proven track record of stable spending without sudden spikes, maybe it is still acceptable to keep cost data limited to finance. Nonetheless, you run the risk of missing optimisation pathways if your environment changes or if external factors (e.g., vendor price adjustments) affect your spending patterns.

In summary, this approach may be “good enough” for organisations with very limited complexity or strictly centralised purchasing structures where cost fluctuations remain low and stable. It can also suffice if you have unwavering trust that top-down oversight alone will detect anomalies. But if you see any potential for cost spikes, new feature adoption, or a desire to empower engineering with cost data, it might be time to consider a more transparent model.

How do I do better?

How do I do better?

If you want to improve beyond “Restricted Billing Visibility,” the next step typically involves democratising cost data. This transition does not mean giving everyone unrestricted access to sensitive financial accounts or payment details. Instead, it centers on making relevant usage and cost breakdowns accessible to those who influence spending decisions, such as product owners, development teams, and DevOps staff, in a manner that is both secure and comprehensible.

Below are tangible ways to create a more open and proactive cost culture:

  1. Role-Based Access to Billing Dashboards

    • Most major cloud providers offer robust billing dashboards that can be securely shared with different levels of detail. For example, you can configure specialised read-only roles that allow developers to see usage patterns and daily cost breakdown without granting them access to critical financial settings.
    • Look into official documentation and solutions from your preferred cloud provider:
    • By carefully configuring role-based access, you enable various teams to monitor cost drivers without exposing sensitive billing details such as invoicing or payment methods.

  2. Regular Cost Review Meetings

    • Schedule short, recurring meetings (monthly or bi-weekly) where finance, engineering, operations, and leadership briefly review cost trends. This fosters collaboration, encourages data-driven decisions, and allows everyone to ask questions or highlight anomalies.
    • Ensure these sessions focus on actionable items. For instance, if a certain service’s spend has doubled, discuss whether that trend reflects legitimate growth or a misconfiguration that can be quickly fixed.

  3. Automated Cost Alerts for Key Stakeholders

    • Integrating cost alerts into your organisational communication channels can be a game changer. Instead of passively waiting for monthly bills, set up cost thresholds, daily or weekly cost notifications, or usage anomalies that get shared in Slack, Microsoft Teams, or email distribution lists.
    • This approach ensures that the right people see cost increases in near real-time. If a developer spins up a large instance for testing and forgets to turn it off, you can catch that quickly.
    • Each major provider offers alerting and budgeting features:

  4. Cost Dashboards Embedded into Engineering Workflows

    • Rather than expecting developers to remember to check a separate financial console, embed cost insights into the tools they already use. For example, if your organisation relies on a continuous integration/continuous deployment (CI/CD) pipeline, you can integrate scripts or APIs that retrieve daily cost data and present them in your pipeline dashboards or as part of a daily Slack summary.
    • Some organisations incorporate cost metrics into code review processes, ensuring that changes with potential cost implications (like selecting a new instance type or enabling a new managed service) are considered from both a technical and financial perspective.

  5. Empowering DevOps with Cost Governance

    • If you have a DevOps or platform engineering team, involve them in evaluating cost optimisation best practices. By giving them partial visibility into real-time spend data, they can quickly adjust scaling policies, identify over-provisioned resources, or investigate usage anomalies before a bill skyrockets.
    • You might create a “Cost Champion” role in each engineering squad—someone who monitors usage, implements resource tagging strategies, and ensures that the rest of the team remains mindful of cloud spend.

  6. Use of FinOps Principles

    • The emerging discipline of FinOps (short for “Financial Operations”) focuses on bringing together finance, engineering, and business stakeholders to drive financial accountability. Adopting a FinOps mindset means cost visibility becomes a shared responsibility, with iterative improvement at its core.
    • Consider referencing frameworks like the FinOps Foundation’s Principles to learn about building a culture of cost ownership, unit economics, and cross-team collaboration.

  7. Security and Compliance Considerations

    • Improving visibility does not mean exposing sensitive corporate finance data or violating compliance rules. Many organisations adopt an approach where top-level financial details (like credit card info or total monthly invoice) remain restricted, but usage-based metrics, daily cost reports, and resource-level data are made available.
    • Work with your governance or risk management teams to ensure that any expanded visibility aligns with data protection regulations and internal security policies.

By following these strategies, you shift from a guarded approach—where only finance or management see the details—to a more inclusive cost culture. The biggest benefit is that your engineering teams gain the insight they need to optimise continuously. Rather than discovering at the end of the month that a test environment was running at full throttle, teams can detect and fix potential overspending early. Over time, this fosters a sense of shared cost responsibility, encourages more efficient design decisions, and drives proactive cost management practices across the organisation.

Proactive Spend Commitment by Finance: The finance team uses billing information to make informed decisions about pre-committed cloud spending where it’s deemed beneficial.

How to determine if this good enough

In many organisations, cloud finance teams or procurement specialists negotiate contracts with cloud providers for discounted rates based on committed spend, often referred to as “Reserved Instances,” “Savings Plans,” “Committed Use Discounts,” or other vendor-specific programs. This approach can result in significant cost savings if done correctly. Understanding when this level of engagement is “good enough” often depends on the maturity of your cost forecasting, the stability of your workloads, and the alignment of these financial decisions with actual technical usage patterns.

  1. Consistent, Predictable Workloads

    • If your application usage is relatively stable or predictably growing, pre-committing spend for a year or multiple years may deliver significant savings. In these situations, finance-led deals—where finance is looking at historical bills and usage curves—can cover the majority of your resource requirements without risking over-commitment.
    • This might be “good enough” if your organisation already has a stable architecture and does not anticipate major changes that could invalidate these predictions.

  2. Finance Has Access to Accurate Usage Data

    • The success of pre-commit or reserved instances depends on the accuracy of usage forecasts. If finance can access granular, up-to-date usage data from your environment—and if that data is correct—then they can make sound financial decisions regarding commitment levels.
    • This approach is likely “good enough” if your technical teams and finance teams have established a reliable process for collecting and interpreting usage metrics, and if finance is skilled at comparing on-demand rates with potential discounts.

  3. Minimal Input from Technical Teams

    • Sometimes, organisations rely heavily on finance to decide how many reserved instances or committed usage plans to purchase. If your technical environment is not highly dynamic or if there is low risk that engineering changes will undermine those pre-commit decisions, centralising decision-making in finance might be sufficient.
    • That said, if your environment is subject to bursts of innovation, quick scaling, or sudden shifts in resource types, you risk paying for commitments that do not match your actual usage. If you do not see a mismatch emerging, you might feel comfortable with the status quo.

  4. No Urgent Need for Real-Time Adjustments

    • One reason an exclusively finance-led approach might still be “good enough” is that you have not observed frequent or large mismatches between your committed usage and your actual consumption. The cost benefits appear consistent, and you have not encountered major inefficiencies (like leftover capacity from partially utilised commitments).
    • If your workloads are largely static or have a slow growth pattern, you may not require real-time collaboration with engineering. Under those circumstances, a purely finance-driven approach can still yield moderate or even significant savings.

  5. Stable Vendor Relationships

    • Some organisations prefer to maintain strong partnerships with a single cloud vendor and do not plan on multi-cloud or vendor migration strategies. If you anticipate staying with that vendor for the long haul, pre-commits become less risky.
    • If you have confidence that your vendor’s future services or pricing changes will not drastically shift your usage patterns, you might view finance’s current approach as meeting your needs.

However, this arrangement can quickly become insufficient if your organisation experiences frequent changes in technology stacks, product lines, or scaling demands. It may also be suboptimal if you do not track how the commitments are being used—or if finance does not engage with the technical side to refine usage estimates.

How do I do better?

How do I do better?

To enhance a “Proactive Spend Commitment by Finance” model, organisations often evolve toward deeper collaboration between finance, engineering, and product teams. This ensures that negotiated contracts and reserved purchasing decisions accurately reflect real workloads, growth patterns, and future expansions. Below are methods to improve:

  1. Integrated Forecasting and Capacity Planning

    • Instead of having finance make decisions based purely on past billing, establish a forecasting model that includes planned product launches, major infrastructure changes, or architectural transformations.
    • Encourage technical teams to share roadmaps (e.g., upcoming container migrations, new microservices, or expansions into different regions) so finance can assess whether existing reservation strategies are aligned with future reality.
    • By merging product timelines with historical usage data, finance can negotiate better deals and tailor them closely to the actual environment.

  2. Dynamic Monitoring of Reservation Coverage

  3. Cross-Functional Reservation Committees

    • Create a cross-functional group that meets quarterly or monthly to decide on reservation purchases or modifications. In this group, finance presents cost data, while engineering clarifies usage patterns and product owners forecast upcoming demand changes.
    • This ensures that any new commits or expansions account for near-future workloads rather than only historical data. If you adopt agile practices, incorporate these reservation reviews as part of your sprint cycle or program increment planning.

  4. Leverage Spot or Preemptible Instances for Variable Workloads

    • An advanced tactic is to blend long-term reservations for predictable workloads with short-term, highly cost-effective instance types—such as AWS Spot Instances, Azure Spot VMs, GCP Preemptible VMs, or OCI Preemptible Instances—for workloads that can tolerate interruptions.
    • Finance-led pre-commits for baseline needs plus engineering-led strategies for ephemeral or experimental tasks can minimise your total cloud spend. This synergy requires communication between finance and engineering so that the latter group can identify which workloads can safely run on spot capacity.

  5. Refining Commitment Levels and Terms

    • If your cloud vendor offers multiple commitment term lengths (e.g., 1-year vs. 3-year reservations, partial upfront vs. full upfront) and different coverage tiers, refine your strategy to match usage stability. For example, if 60% of your workload is unwavering, consider 3-year commits; if another 20% fluctuates, opt for 1-year or on-demand.
    • Over time, as your usage data becomes more accurate and your architecture stabilises, you can shift more workloads into longer-term commitments for greater discounts. Conversely, if your environment is in flux, keep your commitments lighter to avoid overpaying.

  6. Unit Economics and Cost Allocation

    • Enhance your commitment strategy by tying it to unit economics—i.e., cost per customer, cost per product feature, or cost per transaction. Once you can express your cloud bills in terms of product-level or service-level metrics, you gain more clarity on which areas most justify pre-commits.
    • If you identify a specific product line that reliably has N monthly active users, and you have stable usage patterns there, you can base reservations on that product’s forecast. Then, the cost savings from reservations become more attributable to specific products, making budgeting and cost accountability smoother.

  7. Ongoing Financial-Technical Collaboration

    • Beyond initial negotiations, keep the lines of communication open. Cloud resource usage is dynamic, particularly with continuous integration and deployment practices. Having monthly or quarterly check-ins between finance and engineering ensures you track coverage, refine cost models, and respond quickly to usage spikes or dips.
    • Consider forming a “FinOps” group if your cloud usage is substantial. This multi-disciplinary team can use data from daily or weekly cost dashboards to fine-tune reservations, detect anomalies, and champion cost-optimisation strategies across the business.

By progressively weaving in these improvements, you move from a purely finance-led contract negotiation model to one where decisions about reserved spending or commitments are strongly informed by real-time engineering data and future product roadmaps. This more holistic approach leads to higher reservation utilisation, fewer wasted commitments, and better alignment of your cloud spending with actual business goals. The result is typically a more predictable cost structure, improved cost efficiency, and reduced risk of paying for capacity you do not need.

Cost-Effective Resource Management: Cloud environments and applications are configured for cost-efficiency, such as automatically shutting down or scaling down non-production environments during off-hours.

How to determine if this good enough

Cost-Effective Resource Management typically reflects an environment where you have implemented proactive measures to eliminate waste in your cloud infrastructure. Common tactics include turning off development or testing environments at night, using auto-scaling to handle variable load, and continuously auditing for idle resources. The question becomes whether these tactics alone suffice for your organisational goals or if further improvements are necessary. To evaluate, consider the following:

  1. Monitoring Actual Savings

    • If you have systematically scheduled non-production workloads to shut down or scale down during off-peak hours, you should be able to measure the direct savings on your monthly bill. Compare your pre-implementation spending to current levels, factoring in seasonal usage patterns. If your cost has dropped significantly, you might conclude that the approach is providing tangible value.
    • However, cost optimisation rarely stops at shutting down test environments. If you still observe large spikes in bills outside of work hours or suspect that production environments remain over-provisioned, you may not be fully leveraging the potential.

  2. Resource Right-sizing

    • Simply scheduling off-hours shutdowns is beneficial, but right-sizing resources can yield equally impactful or even greater results. For instance, if your production environment runs on instance types or sizes that are consistently underutilised, there is an opportunity to downsize.
    • If you have not yet performed or do not regularly revisit right-sizing exercises—analyzing CPU and memory usage, optimising storage tiers, or removing unused IP addresses or load balancers—your “Cost-Effective Resource Management” might only be addressing part of the savings puzzle.

  3. Lifecycle Management of Environments

    • Shutting down entire environments for nights or weekends helps reduce cost, but it is only truly effective if you also manage ephemeral environments responsibly. Are you spinning up short-lived staging or test clusters for continuous integration, but forgetting to tear them down after usage?
    • If you have robust processes or automation that handle the entire lifecycle—creation, usage, shutdown, deletion—for these environments, then your current approach could be “good enough.” If not, orphaned or abandoned environments might still be draining budgets.

  4. Auto-Scaling Maturity

    • Auto-scaling is a cornerstone of cost-effective resource management. If you have implemented it for your production and major dev/test environments, that may appear “good enough” initially. But is your scaling policy well-optimised? Are you aggressively scaling down during low traffic, or do you keep large buffer capacities?
    • Evaluate logs to check if you have frequent periods of near-zero usage but remain scaled up. If auto-scaling triggers are not finely tuned, you could be missing out on further cost reductions.

  5. Cost vs. Performance Trade-Offs

    • Some teams accept a degree of cost inefficiency to ensure maximum performance. If your organisation is comfortable paying for extra capacity to handle traffic bursts, the existing environment might be adequate. But if you have not explicitly weighed the financial cost of that performance margin, you could be inadvertently overspending.
    • “Good enough” might be an environment where you have at least set baseline checks to prevent runaway spending. Yet, if you want to refine performance-cost trade-offs further, additional tuning or service re-architecture could unlock more savings.

  6. Empowerment of Teams

    • Another dimension is whether only a small ops or DevOps group is responsible for shutting down resources or if the entire engineering team is cost-aware. If the latter is not the case, you may have manual processes that lead to inconsistent application of off-hour shutdowns. A more mature approach would see each team taking responsibility for their resource usage, aided by automation.
    • If your processes remain centralised and manual, your approach might hit diminishing returns as you grow. Achieving real momentum often requires embedding cost awareness into the entire software development lifecycle.

When you reflect on these factors, “Cost-Effective Resource Management” is likely “good enough” if you have strong evidence of direct savings, a minimal presence of unused resources, and a consistent approach to shutting down or scaling your environments. If you still detect untracked resources, underused large instances, or an absence of automated processes, there are plenty of next steps to enhance your strategy.

How do I do better?

How do I do better?

If you wish to refine your cost-efficiency, consider adding more sophisticated processes, automation, and cultural practices. Here are ways to evolve:

  1. Implement More Granular Auto-Scaling Policies

  2. Use Infrastructure as Code for Environment Management

    • Instead of ad hoc creation and shutdown scripts, adopt Infrastructure as Code (IaC) tools (e.g., Terraform, AWS CloudFormation, Azure Bicep, Google Deployment Manager, or OCI Resource Manager) to version-control environment configurations. Combine IaC with schedule-based or event-based triggers.
    • This approach ensures that ephemeral environments are consistently built and torn down, leaving minimal risk of leftover resources. You can also implement automated tagging to track cost by environment, team, or project.

  3. Re-Architect for Serverless or Containerised Workloads

    • If your application can tolerate stateless, event-driven, or container-based architectures, consider adopting serverless computing (e.g., AWS Lambda, Azure Functions, GCP Cloud Functions, OCI Functions) or container orchestrators (e.g., Kubernetes, Docker Swarm).
    • These models often scale to zero when no requests are active, ensuring you only pay for actual usage. While not all workloads are suitable, re-architecting certain components can yield significant cost improvements.

  4. Optimise Storage and Networking

    • Cost-effective management extends beyond compute. Look for opportunities to move infrequently accessed data to cheaper storage tiers, such as object storage archive classes or lower-performance block storage. Configure lifecycle policies to purge logs or snapshots after a specified retention.
    • Monitor data transfer costs between regions, availability zones, or external endpoints. If your architecture unnecessarily routes traffic through costlier paths, consider direct inter-region or peering solutions that reduce egress charges.

  5. Scheduled Resource Hibernation and Wake-Up Processes

    • Extend beyond typical off-hour shutdowns by creating fully automated schedules for every environment that does not require 24/7 availability. For instance, set a policy to shut down dev/test resources at 7 p.m. local time, and spin them back up at 8 a.m. the next day.
    • Tools or scripts can detect usage anomalies (e.g., someone working late) and override the schedule or send a prompt to confirm if the environment should remain active. This approach ensures maximum cost avoidance, especially for large dev clusters or specialised GPU instances.

  6. Incorporate Cost Considerations into Code Reviews and Architecture Decisions

    • Foster a culture in which cost is a first-class design principle. During code reviews, developers might highlight the cost implications of using a high-tier database service, retrieving data across regions, or enabling a premium feature.
    • Architecture design documents should include estimated cost breakdowns, referencing official pricing details for the services involved. Over time, teams become more adept at spotting potential overspending.

  7. Automated Auditing and Cleanup

    • Implement scripts or tools that run daily or weekly to detect unattached volumes, unused IP addresses, idle load balancers, or dormant container images. Provide automated cleanup or at least raise alerts for manual review.
    • Many cloud providers have built-in recommendations engines:

  8. Track and Celebrate Savings

    • Publicise cost optimisation wins. If an engineering team shaved 20% off monthly bills by fine-tuning auto-scaling, celebrate that accomplishment in internal communications. Show the before/after metrics to encourage others to follow suit.
    • This positive reinforcement helps maintain momentum and fosters a sense of shared ownership.

By layering these enhancements, you move beyond basic scheduling or minimal auto-scaling. Instead, you cultivate a deeply ingrained practice of continuous optimisation. You harness automation to enforce best practices, integrate cost awareness into everyday decisions, and systematically re-architect services for maximum efficiency. Over time, the result is a lean cloud environment that can expand when needed but otherwise runs with minimal waste.

Cost-Aware Development Practices: Developers and engineers have daily visibility into cloud costs and are encouraged to consider the financial impact of their choices in the development phase.

How to determine if this good enough

Introducing “Cost-Aware Development Practices” means your engineering teams are no longer coding in a vacuum. Instead, they have direct or near-direct access to cost data and incorporate budget considerations throughout their software lifecycle. However, measuring if this approach is “good enough” requires assessing how deeply cost awareness is embedded in day-to-day technical activities, as well as the outcomes you achieve.

  1. Extent of Developer Engagement

    • If your developers see cloud cost dashboards daily but rarely take any action based on them, the visibility may not be translating into tangible benefits. Are they actively tweaking infrastructure choices, refactoring code to reduce memory usage, or questioning the necessity of certain services? If not, your “awareness” might be superficial.
    • Conversely, if you see frequent pull requests that address cost inefficiencies, your development team is likely using their visibility effectively.

  2. Integration in the Software Development Lifecycle

    • Merely giving developers read access to a billing console is insufficient. If your approach is truly effective, cost discussions happen early in design or sprint planning, not just at the end of the month. The best sign is that cost considerations appear in architecture diagrams, code reviews, and platform selection processes.
    • If cost is still an afterthought—addressed only when a finance or leadership team raises an alarm—then the practice is not yet “good enough.”

  3. Tooling and Automated Feedback

    • Effective cost awareness often involves integrated tooling. For instance, developers might see near real-time cost metrics in their Git repositories or continuous integration workflows. They might receive a Slack notification if a new branch triggers resources that exceed certain thresholds.
    • If your environment lacks this real-time or near-real-time feedback loop, and developers only see cost data after big monthly bills, the awareness might be lagging behind actual usage.

  4. Demonstrable Cost Reductions

    • A simple yardstick is whether your engineering teams can point to quantifiable cost reductions linked to design decisions or code changes. For example, a team might say, “We replaced a full-time VM with a serverless function and saved $2,000 monthly.”
    • If such examples are sparse or non-existent, you might suspect that cost awareness is not yet translating into meaningful changes.

  5. Cultural Embrace

    • A “good enough” approach sees cost awareness as a normal part of engineering culture, not an annoying extra. Team leads, product owners, and developers frequently mention cost in retrospectives or stand-ups.
    • If referencing cloud spend or budgets still feels taboo or is seen as “finance’s job,” you have further to go.

  6. Alignment with Company Goals

    • Finally, consider how your cost-aware practices align with broader business goals—whether that be margin improvement, enabling more rapid scaling, or launching new features within certain budgets. If your engineering changes consistently support these objectives, your approach might be sufficiently mature.
    • If leadership is still blindsided by unexpected cost overruns or if big swings in usage go unaddressed, it is likely that your cost-aware culture is not fully effective.

How do I do better?

How do I do better?

If you want to upgrade your cost-aware development environment, you can deepen the integration of financial insight into everyday engineering. Below are practical methods:

  1. Enhance Toolchain Integrations

    • Provide cost data directly in the platforms developers use daily:
      • Pull Request Annotations: When a developer opens a pull request in GitHub or GitLab that adds new cloud resources (e.g., creating a new database or enabling advanced analytics), an automated comment could estimate the monthly or annual cost impact.
      • IDE Plugins: Investigate or develop plugins that estimate cost implications of certain library or service calls. While advanced, such solutions can drastically reduce guesswork.
      • CI/CD Pipeline Steps: Incorporate cost checks as a gating mechanism in your CI/CD process. If a change is projected to exceed certain cost thresholds, it triggers a review or a labeled warning.

  2. Reward and Recognition Systems

    • Implement a system that publicly acknowledges or rewards teams that achieve significant cost savings or code optimisations that reduce the cloud bill. This can be a monthly “cost champion” award or a highlight in the company-wide newsletter.
    • Recognising teams for cost-smart decisions helps embed a culture where financial prudence is celebrated alongside feature delivery and reliability.

  3. Cost Education Workshops

    • Host internal workshops or lunch-and-learns where experts (whether from finance, DevOps, or a specialised FinOps team) explain how cloud billing works, interpret usage graphs, or share best practices for cost-efficient coding.
    • Make these sessions as practical and example-driven as possible: walk developers through real code and show the difference in cost from alternative approaches.

  4. Tagging and Chargeback/Showback Mechanisms

    • Encourage consistent resource tagging so that each application component or service is clearly attributed to a specific team, project, or feature. This tagging data feeds into cost reports that let you see which code bases or squads are driving usage.
    • You can then implement a “showback” model (where each team sees the monthly cost of their resources) or a “chargeback” model (where those costs directly affect team budgets). Such financial accountability often motivates more thoughtful engineering decisions.

  5. Guidelines and Architecture Blueprints

    • Produce internal reference guides that show recommended patterns for cost optimisation. For example, specify which database types or instance families are preferred for certain workloads. Provide example Terraform modules or CloudFormation templates that are pre-configured for cost-efficiency.
    • Encourage developers to consult these guidelines when designing new systems. Over time, the default approach becomes inherently cost-aware.

  6. Frequent Feedback Loops

    • Implement daily or weekly cost digests that are automatically posted in relevant Slack channels or email lists. These digests highlight the top 5 cost changes from the previous period, giving engineering teams rapid insight into where spend is shifting.
    • Additionally, create a channel or forum where developers can ask cost-related questions in real time, ensuring they do not have to guess how a new feature might affect the budget.

  7. Collaborative Budgeting and Forecasting

    • For upcoming features or architectural revamps, involve engineers in forecasting the cost impact. By inviting them into the financial planning process, you ensure they understand the budgets they are expected to work within.
    • Conversely, finance or product managers can learn from engineers about the real operational complexities, leading to more accurate forecasting and fewer unrealistic cost targets.

  8. Adopt a FinOps Mindset

    • Expand on the FinOps principles beyond finance alone. Encourage all engineering teams to take part in continuous cost optimisation cycles—inform, optimise, and operate. In these cycles, you measure usage, identify opportunities, experiment with changes, and track results.
    • Over time, cost efficiency becomes an ongoing practice rather than a one-time initiative.

By adopting these approaches, you elevate cost awareness from a passive, occasional concern to a dynamic, integrated element of day-to-day development. This deeper integration helps your teams design, code, and deploy with financial considerations in mind—often leading to innovative solutions that deliver both performance and cost savings.

Comprehensive Cost Management and Optimisation: Multi-tier spend alerts are configured to notify various levels of the business for immediate action. Developers and engineers regularly review and prioritise changes to improve cost-effectiveness significantly.

Comprehensive Cost Management and Optimisation represents a mature stage in your organisation’s journey toward efficient cloud spending. At this point, cost transparency and accountability span multiple layers—from frontline developers to senior leadership. You have automated alerting structures in place to catch anomalies quickly, you track cost optimisation initiatives with the same rigor as feature delivery, and you’ve embedded cost considerations into operational runbooks. Below are key characteristics and actionable guidance to maintain or further refine this approach:

  1. Robust and Granular Alerting Mechanisms

    • In a comprehensive model, you’ve configured multi-tier alerts that scale with the significance of cost changes. For instance, a modest daily threshold might notify a DevOps Slack channel, while a larger monthly threshold might email department heads, and an even bigger spike might trigger urgent notifications to executives.
    • Ensure these alerts are not just numeric triggers (e.g., “spend exceeded $X”), but also usage anomaly detections. For example, if a region’s usage doubles overnight or a new instance type’s cost surges unexpectedly, the right people receive immediate alerts.
    • Each major cloud provider offers flexible budgeting and cost anomaly detection:

  2. Cross-Functional Cost Review Cadences

    • You have regular reviews—often monthly or quarterly—where finance, engineering, operations, and leadership analyze trends, track the outcomes of previous optimisation initiatives, and identify new areas of improvement.
    • During these sessions, metrics might include cost per application, cost per feature, cost as a percentage of revenue, or carbon usage if sustainability is also a focus. This fosters a culture where cost is not an isolated item but a dimension of overall business performance.

  3. Prioritisation of Optimisation Backlog

    • In a comprehensive system, cost optimisation tasks are often part of your backlog or project management tool (e.g., Jira, Trello, or Azure Boards). Engineers and product owners treat these tasks with the same seriousness as performance issues or feature requests.
    • The backlog might include refactoring older services to more modern compute platforms, consolidating underutilised databases, or migrating certain workloads to cheaper regions. By regularly ranking and scheduling these items, you show a commitment to continuous improvement.

  4. End-to-End Visibility into Cost Drivers

    • True comprehensiveness means your teams can pinpoint exactly which microservice, environment, or user activity drives each cost spike. This is usually achieved through detailed tagging strategies, advanced cost allocation methods, or third-party tools that break down usage in near-real-time.
    • If a monthly cost review reveals that data transfer is trending upward, you can directly tie it to a new feature that streams large files, or a microservice that inadvertently calls an external API from an expensive region. You then take targeted action to reduce those costs.

  5. Forecasting and Capacity Planning

    • Beyond reviewing past or current costs, you systematically forecast future spend based on product roadmaps and usage growth. This might involve building predictive models or leveraging built-in vendor forecasting tools.
    • Finance and engineering collaborate to refine these forecasts, adjusting resource reservations or scaling strategies accordingly. For example, if you anticipate doubling your user base in Q3, you proactively adjust your reservations or budgets to avoid surprises.

  6. Policy-Driven Automation and Governance

    • Comprehensive cost management often includes policy enforcement. For instance, you may have automated guardrails that prevent developers from spinning up large GPU instances without approval, or compliance checks that ensure data is placed in cost-efficient storage tiers when not actively in use.
    • Some organisations implement custom or vendor-based governance solutions that block resource creation if it violates cost or security policies. This ensures cost best practices become part of the standard operating procedure.

  7. Continuous Feedback Loop and Learning

    • The hallmark of a truly comprehensive approach is the cyclical process of learning from cost data, making improvements, measuring outcomes, and then repeating. Over time, each iteration yields a more agile and cost-efficient environment.
    • Leadership invests in advanced analytics, A/B testing for cost optimisation strategies (e.g., testing a new auto-scaling policy in one region), and might even pilot different cloud vendors or hybrid deployments to see if further cost or performance benefits can be achieved.

  8. Scaling Best Practices Across the Organisation

    • In a large enterprise, you may have multiple business units or product lines. A comprehensive approach ensures that cost management practices do not remain siloed. You create a central repository of best practices, standard operating procedures, or reference architectures to spread cost efficiency across all teams.
    • This might manifest as an internal “community of practice” or “center of excellence” for FinOps, where teams share success stories, compare metrics, and continually push the envelope of optimisation.

  9. Aligning Cost Optimisation with Business Value

    • Ultimately, cost optimisation should serve the broader strategic goals of the business—whether to improve profit margins, free up budget for innovation, or support sustainability commitments. In the most advanced organisations, decisions around cloud architecture tie directly to metrics like cost per transaction, cost per user, or cost per new feature.
    • Senior executives see not just raw cost figures but also how those costs translate to business outcomes (e.g., revenue, user retention, or speed of feature rollout). This alignment cements cost optimisation as a catalyst for better products, not just an expense reduction exercise.

  10. Evolving Toward Continuous Refinement

    • Even with a high level of maturity, the cloud landscape shifts rapidly. Providers introduce new instance types, new discount structures, or new services that might yield better cost-performance ratios. An ongoing commitment to learning and experimentation keeps you ahead of the curve.
    • Your monthly or quarterly cost reviews might always include a segment to evaluate newly released vendor features or pricing models. By piloting or migrating to these offerings, you ensure you do not stagnate in a changing market.

In short, “Comprehensive Cost Management and Optimisation” implies that every layer—people, process, and technology—is geared toward continuous financial efficiency. Alerts ensure no cost anomaly goes unnoticed, cross-functional reviews nurture a culture of accountability, and an active backlog of cost-saving initiatives keeps engineering engaged. Over time, this integrated approach can yield substantial and sustained reductions in cloud spend while maintaining or even enhancing the quality and scalability of your services.

Keep doing what you’re doing, and consider writing up your experiences in blog posts or internal knowledge bases, then submitting pull requests to this guidance so that others can learn from your successes. By sharing, you extend the culture of cost optimisation not only across your organisation but potentially across the broader industry.

What strategies guide your decisions on geographical distribution and operational management of cloud workloads and data storage?

Intra-Region Distribution: Workloads and data are spread across multiple availability zones within a single region to enhance availability and resilience.

How to determine if this good enough

  • Moderate Tolerance for Region-Level Outages
    You may handle an AZ-level failure but might be vulnerable if the entire region goes offline.
  • Improved Availability Over Single AZ
    Achieving at least multi-AZ deployment typically satisfies many public sector continuity requirements, referencing NCSC’s resilience guidelines.
  • Cost vs. Redundancy
    Additional AZ usage may raise costs (like cross-AZ data transfer fees), but many find the availability trade-off beneficial.

If you still have concerns about entire regional outages or advanced compliance demands for multi-region or cross-geography distribution, consider a multi-region approach. NIST SP 800-53 CP (Contingency Planning) controls often encourage broader geographical resiliency if your RPO/RTO goals are strict.

How to do better

Below are rapidly actionable ways to refine an intra-region approach:

  1. Enable Automatic Multi-AZ Deployments

  2. Replicate Data Synchronously

  3. Set AZ-Aware Networking

  4. Regularly Test AZ Failover

    • Induce a partial Availability Zone (AZ) outage or rely on “game days” to ensure applications properly degrade or failover:
    • Ensures systems can handle unexpected disruptions effectively.

  5. Monitor Cross-AZ Costs

By automatically spreading workloads, replicating data in multiple AZs, ensuring AZ-aware networking, regularly testing failover, and monitoring cross-AZ costs, you solidify your organisation’s resilience within a single region while controlling costs.

Selective Multi-Region Utilisation: An additional, legally compliant non-UK region is used for specific purposes, such as non-production workloads, certain data types, or as part of disaster recovery planning.

How to determine if this good enough

  • Basic Multi-Region DR or Lower-Cost Testing
    You might offload dev/test to another region or keep backups in a different region for DR compliance.
  • Minimal Cross-Region Dependencies
    If you only replicate data or run certain non-critical workloads in the second region, partial coverage might suffice.
  • Meets Certain Compliance Needs
    Some public sector entities require data in at least two distinct legal jurisdictions—this setup may address that in limited scope.

If entire production workloads are mission-critical for national services or must handle region-level outages seamlessly, you might consider a more robust multi-region active-active approach. NIST SP 800-34 DR guidelines often advise multi-region for critical continuity.

How to do better

Below are rapidly actionable improvements:

  1. Automate Cross-Region Backups

  2. Schedule Non-Production in Cheaper Regions

    • If cost is a driver, shut down dev/test in off-peak times or run them in a region with lower rates:
      • Referencing your chosen vendor’s regional pricing page.

  3. Establish a Basic DR Plan

  4. Regularly Test Failover

  5. Plan for Data Residency

By automating cross-region backups, offloading dev/test workloads where cost is lower, defining a minimal DR plan, regularly testing failover, and ensuring data residency compliance, you expand from a single-region approach to a modest but effective multi-region strategy.

Capability and Sustainability-Driven Selection: Regions are chosen based solely on their technical capabilities, cost-effectiveness, and environmental sustainability credentials, without any specific technical constraints.

How to determine if this good enough

  • Advanced Region Flexibility
    You pick the region that offers the best HPC, GPU, or AI services, or one with the lowest carbon footprint or cost.
  • Sustainability & Cost Prioritised
    If your organisation strongly values green energy sourcing or cheaper nighttime rates, you shift workloads accordingly.
  • No Hard Legal Data Residency Constraints
    You can store data outside the UK or EEA as permitted, and no critical constraints block you from picking any global region.

If you want to adapt in real time based on cost or carbon intensity or maintain advanced multi-region failover automatically, consider a dynamic approach. NCSC’s guidance on green hosting or multi-region usage and NIST frameworks for dynamic cloud management can guide advanced scheduling.

How to do better

Below are rapidly actionable enhancements:

  1. Sustainability-Driven Tools

  2. Implement Real-Time Cost & Perf Monitoring

  3. Enable Multi-Region Data Sync

  4. Address Latency & End-User Performance

    • For services with user-facing components, consider CDN edges, multi-region front-end load balancing, or local read replicas to ensure acceptable performance.

  5. Document Region Swapping Procedures

    • If you occasionally relocate entire workloads for cost or sustainability, define runbooks or scripts to manage DB replication, DNS updates, and environment spin-up.

By using sustainability calculators to choose greener regions, implementing real-time cost/performance checks, ensuring multi-region data readiness, managing user latency via CDNs or local replicas, and documenting region-swapping, you fully leverage each provider’s global footprint for cost and environmental benefits.

Dynamic and Cost-Sustainable Distribution: Workloads are dynamically allocated across various regions and availability zones, with scheduling optimised for cost-efficiency and sustainability, adapting in real-time to changing conditions.

How to determine if this good enough

Your organisation pursues a true multi-region, multi-AZ dynamic approach. Automated processes shift workloads based on real-time cost (spot prices) or carbon intensity, while preserving performance and compliance. This may be “good enough” if:

  1. Highly Automated Infrastructure

    • You rely on complex orchestration or container platforms that can scale or move workloads near-instantly.

  2. Advanced Observability

    • A robust system of metrics, logging, and anomaly detection ensures seamless adaptation to cost or sustainability triggers.

  3. Continuous Risk & Compliance Checks

    • Even though workloads shift globally, you remain compliant with relevant data sovereignty or classification rules, referencing NCSC data handling or departmental policies.

Nevertheless, you can refine HPC or AI edge cases, adopt chaos testing for dynamic distribution, or integrate advanced zero trust for each region shift. NIST SP 800-207 zero-trust architecture principles can help ensure each region transition remains secure.

How to do better

Below are rapidly actionable methods to refine dynamic, cost-sustainable distribution:

  1. Automate Workload Placement

    • Tools like [AWS Spot Instance with EC2 Fleet, Azure Spot VMs with scale sets, GCP Preemptible VMs, OCI Preemptible Instances] or container orchestrators that factor region costs:
      • referencing vendor cost management APIs or third-party cost analytics.

  2. Use Real-Time Carbon & Pricing Signals

  3. Add Continual Governance

    • Ensure no region usage violates data residency constraints or compliance:
      • referencing NCSC multi-region compliance advice or departmental data classification guidelines.

  4. Embrace Chaos Engineering

  5. Integrate Advanced DevSecOps

    • For each region shift, the pipeline or orchestrator re-checks security posture and cost thresholds in real time.

By automating workload placement with spot or preemptible instances, factoring real-time carbon and cost signals, applying continuous data residency checks, stress-testing region shifts with chaos engineering, and embedding advanced DevSecOps validations, you maintain a dynamic, cost-sustainable distribution model that meets the highest operational and environmental standards for UK public sector services.

Keep doing what you’re doing, and consider blogging about or opening pull requests to share how you handle multi-region distribution and operational management for cloud workloads. This information can help other UK public sector organisations adopt or improve similar approaches in alignment with NCSC, NIST, and GOV.UK best-practice guidance.

Data

How does your organisation identify, classify, and manage its data storage and usage?

Decentralised and Ad Hoc Management: Data management is largely uncoordinated and informal, with limited organisational oversight of data storage locations and types.

How to determine if this good enough

In the “Decentralised and Ad Hoc Management” stage, each department, team, or project might handle data in its own way, with minimal organisational-level policies or guidance. You might consider this setup “good enough” under the following conditions:

  1. Very Small or Low-Risk Datasets

    • If your organisation handles mostly unclassified or minimal-risk data, and the volume is modest enough that the cost of implementing formal oversight isn’t easily justified.

  2. Early Phases or Pilot Projects

    • You might be in a startup-like environment testing new digital services, with no immediate demand for robust data governance.

  3. Minimal Regulatory/Compliance Pressure

    • If you’re not subject to strict data protection, privacy regulations, or public accountability—for example, a small-scale internal project with no personally identifiable information (PII).

  4. Low Complexity

    • If your data usage is straightforward (e.g., only a few spreadsheets or simple cloud storage buckets), with minimal sharing across teams or external partners.

However, for most UK public sector bodies, even “unofficial” data systems can become large or sensitive over time. In addition, compliance requirements from the UK GDPR, the Data Protection Act 2018, and departmental data security policies (e.g., Government Security Classifications) often dictate at least a baseline level of oversight. Therefore, truly “Decentralised and Ad Hoc” management is rarely sustainable.

How to do better

Here are rapidly actionable steps to establish foundational data management and reduce risks:

  1. Identify and Tag All Existing Data Stores

  2. Establish Basic Data Handling Guidelines

    • Document a short set of rules about where teams should store data, who can access it, and minimal security classification steps (e.g., “Use only these approved folders/buckets for OFFICIAL-SENSITIVE data”).
    • Reference the Government Security Classification Policy (GSCP) or departmental guidelines to outline baseline compliance steps.

  3. Enable Basic Monitoring and Access Controls

  4. Educate Teams on Data Sensitivity

    • Run short, targeted training or lunch-and-learns on recognising PII, official data, or other categories.
    • Emphasize that storing data in an “unofficial” manner can violate data protection laws or hamper future compliance efforts.

  5. Draft an Interim Data Policy

    • Outline a simple, interim policy that sets initial standards for usage. For example:
      • "Always store sensitive data (OFFICIAL-SENSITIVE) in an encrypted bucket or database.
      • “Tag resources with project name, data owner, and data sensitivity level.”
    • Having any policy is better than none, setting the stage for more formal governance.

By identifying your data storage resources, applying minimal security tagging, and sharing initial guidelines, you shift from ad hoc practices to a basic, more controlled environment. This foundation paves the way for adopting robust data governance tools and processes down the line.

Team-Based Documentation and Manual Policy Adherence: Each team documents the data they handle, including its schema and sensitivity. Compliance with organisational data policies is managed manually by individual teams.

How to determine if this good enough

Here, you’ve moved from having no formal oversight to each team at least keeping track of their data usage—potentially in spreadsheets or internal wikis. You might view this as sufficient if:

  1. Moderate Complexity but Clear Ownership

    • Each department or project has well-defined data owners who can articulate what data they store, how sensitive it is, and where it resides.

  2. Manual Policy is Consistently Applied

    • You have a basic organisational data policy, and each team enforces it themselves, without heavy central governance.
    • So far, you haven’t encountered major incidents or confusion over compliance.

  3. Low Rate of Cross-Team Data Sharing

    • If data seldom flows between departments, manual documentation might not be overly burdensome.

  4. Acceptable Accuracy

    • Although the process is manual, your teams keep it reasonably up to date. External audits or departmental reviews find no glaring misalignment.

However, manual adherence becomes error-prone as soon as data volumes grow or cross-team collaborations increase. The overhead of maintaining separate documentation can lead to duplication, versioning issues, or compliance gaps—particularly in the UK public sector, where data sharing among services can escalate quickly.

How to do better

Below are rapidly actionable ways to improve upon team-based documentation:

  1. Adopt Centralised Tagging/Labeling Policies

  2. Introduce Lightweight Tools for Schema and Documentation

  3. Standardise on Security and Compliance Checklists

  4. Schedule Quarterly or Semi-Annual Data Reviews

    • Even if managed by each team, commit to an organisational cycle:
      • They update their data inventories, verify classification, and confirm no stale or untagged storage resources.
      • Summarise findings to central governance or a data protection officer for quick oversight.

  5. Motivate with Quick Wins

    • Share success stories: “Team X saved money by archiving old data after a manual review, or prevented a compliance risk by discovering unencrypted PII.”
    • This fosters cultural buy-in and continuous improvement.

By implementing standardised tagging, shared documentation tools, and routine checklists, you enhance consistency and reduce errors. You’re also positioning yourself for the next maturity level, which often involves more automated scanning and classification across the organisation.

Inventoried and Classified Data: An inventory of data, created manually or via scanning tools, exists. Data is classified by type (e.g., PII, card data), sensitivity, and regulatory requirements (e.g., retention, location).

How to determine if this good enough

Now you have a formal data inventory that might combine manual inputs from teams and automated scans to detect data types (e.g., presence of national insurance numbers or other PII). This can be “good enough” if:

  1. You Know Where Your Data Lives

    • You’ve mapped key data stores—cloud buckets, databases, file systems—and keep these records relatively up to date.

  2. Consistent Data Classification

    • You apply recognised categories like “OFFICIAL,” “OFFICIAL-SENSITIVE,” “RESTRICTED,” or other departmental terms.
    • Teams are aware of which data must follow special controls (e.g., personal data under UK GDPR, payment card data under PCI-DSS, etc.).

  3. Proactive Compliance

    • You can respond to data subject requests or FOI (Freedom of Information) inquiries quickly, because you know which systems contain personal or sensitive data.
    • Auditors or data protection officers can trace the location of specific data sets.

  4. Clarity on Retention and Disposal

    • You have at least basic retention timelines for certain data types (e.g., “Keep these records for 2 years, then archive or securely delete”).
    • This helps you reduce storage bloat and security risk.

If your organisation can maintain this inventory without excessive overhead, meet compliance requirements, and quickly locate or delete data upon request, you might be satisfied. However, if data usage is growing or you’re facing more complex analytics and cross-team usage, you likely need more advanced governance, lineage tracking, and automation.

How to do better

To refine your “Inventoried and Classified Data” approach, apply these rapidly actionable enhancements:

  1. Automate Scanning and Classification

  2. Introduce Basic Lineage Tracing

  3. Align with Legal & Policy Requirements

  4. Create a Single “Data Inventory” Dashboard

    • Consolidate classification statuses in a simple dashboard or spreadsheet so data governance leads can track changes at a glance.
    • If possible, generate monthly or quarterly “data classification health” reports.

  5. Provide Self-Service Tools for Teams

    • Offer them a quick way to see if their new dataset might include sensitive fields or which storage option is recommended for OFFICIAL-SENSITIVE data.
    • Maintaining “responsible autonomy” fosters compliance while reducing central bottlenecks.

With scanning, lineage insights, policy-aligned retention, and better visibility, you not only maintain your inventory but move it toward a dynamic, living data map. This sets the stage for deeper data understanding and advanced catalog solutions.

Reviewed and Partially Documented Data Understanding: There’s a comprehensive understanding of data location, classification, and sensitivity, with regular compliance reviews. Data lineage is generally understood but not consistently documented.

How to determine if this good enough

In this phase, your organisation has established processes to classify and review data regularly. You likely have:

  1. Well-Established Inventory and Processes

    • You know exactly where crucial data resides (cloud databases, file shares, analytics platforms).
    • Teams reliably classify new data sets, typically with centralised or automated oversight.

  2. Ongoing Compliance Audits

    • Internal audits or external assessors confirm that data is generally well-managed, meeting security classifications and retention rules.
    • Incidents or policy violations are rare and quickly addressed.

  3. Partial Lineage Documentation

    • Teams can verbally or via some diagrams explain how data flows through the organisation.
    • However, it’s not uniformly captured in a single system or data catalog.

  4. Confidence in Day-to-Day Operations

    • You have fewer unexpected data exposures or confusion over who can access what.
    • Cost inefficiencies or data duplication might still lurk if lineage isn’t fully integrated into everyday tools.

If your broad compliance posture is solid, and your leadership or data protection officer is satisfied with the frequency of reviews, you might remain comfortable here. Yet incomplete lineage documentation can hamper advanced analytics, complicated cross-team data usage, or hamper efficient data discoverability.

How to do better

Below are rapidly actionable steps to deepen your data lineage and documentation:

  1. Adopt or Expand a Data Catalog with Lineage Features

  2. Create a Standard Operating Procedure for Lineage Updates

    • Whenever a new data pipeline is created or an ETL job changes, staff must add or adjust lineage documentation.
    • Ensure this ties into your DevOps or CI/CD process:
      • E.g., new code merges automatically trigger updates in Purview or Data Catalog.

  3. Encourage Data Reuse and Collaboration

    • With partial lineage, teams might still re-collect or duplicate data. Create incentives for them to discover existing data sets:
      • Host a monthly “Data Discovery Forum” or internal knowledge-sharing session.
      • Highlight “success stories” where reusing a known dataset saved time or reduced duplication.

  4. Set Up Tiered Access Policies

  5. Integrate with Risk and Compliance Dashboards

    • If you have a departmental risk register, link data classification/lineage issues into that.
    • This ensures any changes or gaps in lineage are recognised as potential compliance or operational risks.

By systematically building out lineage features and embedding them in everyday workflows, you move closer to a truly integrated data environment. Over time, each dataset’s path through your infrastructure becomes transparent, boosting collaboration, reducing duplication, and easing regulatory compliance.

Advanced Data Catalog and Lineage Tracking: A detailed data catalog exists, encompassing data types and metadata. It includes a user-friendly glossary, quality metrics, use cases, and thorough tracking of data lineage.

How to determine if this good enough

In this final stage, your organisation has an extensive data catalog that covers:

  1. Comprehensive Metadata and Glossary

    • You store definitions, owners, classification details, transformations, and usage patterns in a single platform.
    • Non-technical staff can also search and understand data context easily (e.g., “Which dataset includes housing records for local authorities?”).

  2. Automated Lineage from Source to Consumption

    • ETL pipelines, analytics jobs, and data transformations are captured, so you see exactly how data moves from one place to another.
    • If a compliance or FOI request arises, you can trace the entire path of relevant data instantly.

  3. Embedded Data Quality and Governance

    • The catalog might track data quality metrics (e.g., completeness, validity, duplicates) and flags anomalies.
    • Governance teams can set or update policy rules in the catalog, automatically enforcing them across various tools.

  4. High Reusability and Collaboration

    • Teams discover and reuse existing data sets rather than re-collect or replicate them.
    • Cross-departmental projects benefit from consistent definitions and robust lineage, accelerating digital transformation within the UK public sector.

If you meet these criteria with minimal friction or overhead, your advanced catalog approach is likely “good enough.” Nonetheless, technology and data demands evolve—particularly with new AI/ML, geospatial, or real-time streaming data. Ongoing iteration keeps your catalog valuable and aligned with shifting data strategies.

How to do better

Even at the highest maturity, here are actionable ways to refine:

  1. Incorporate Real-Time or Streaming Data

  2. Add Automated Data Quality Rules and Alerts

    • Configure threshold-based triggers that check data quality daily:
      • e.g., “If more than 5% of new rows fail validation, alert the data steward.”
    • Some vendor-native tools or third-party solutions can embed these checks in your data pipeline or catalog.

  3. Leverage AI/ML to Classify and Suggest Metadata

  4. Integrate Catalog with Wider Public Sector Ecosystems

    • If your data catalog can integrate with cross-government data registries or share metadata with partner organisations, you reduce duplication and improve interoperability. For instance:
      • Some local authorities or NHS trusts might share standardised definitions or GDS guidelines.
      • Tools or APIs that facilitate federation with external catalogs can open up broad data collaboration.

  5. Continuously Evaluate Security, Access, and Usage

    • Review who actually accesses data vs. who is authorised, adjusting policies based on usage patterns.
    • If certain data sets see heavy usage from a new department, ensure lineage, classification, and approvals remain correct.

At this advanced level, your main goal is to keep your data catalog living, dynamic, and well-integrated with the rest of your technology stack and governance frameworks. By embracing new data sources, automating quality checks, leveraging ML classification, and ensuring interoperability across the UK public sector, you solidify your position as a model of data governance and strategic data management.

Keep doing what you’re doing, and consider publishing blog posts or internal case studies about your data governance journey. Submit pull requests to this guidance or relevant public sector repositories to share innovative approaches. By swapping best practices, we collectively improve data maturity, compliance, and service quality across the entire UK public sector.

What is your approach to managing data retention within your organisation?

Organisation-Level Policy Awareness: Data retention policies are defined at the organisation level, and all projects/programs are aware of their specific responsibilities.

How to determine if this good enough

If your entire organisation has a defined data retention policy—aligning with UK legislative requirements (such as the Data Protection Act 2018, UK GDPR) or departmental mandates—and all relevant teams know they must comply, you might consider this stage “good enough” under these conditions:

  1. Clear, Written Policy

    • Your organisation publishes retention durations for various data types, including official government data, personal data, or any data with a defined statutory retention period.

  2. Widespread Awareness

    • Projects and programs understand how long to store data (e.g., 2 years, 7 years, or indefinite for certain record types).
    • Staff can articulate the policy at a basic level when asked.

  3. Minimal Enforcement Overhead

    • If your data is relatively small or low-risk, the cost of automating or auditing might not seem immediately justified.
    • No major incidents or compliance breaches have surfaced yet.

  4. Simplicity Over Complexity

    • You have a “one-size-fits-all” approach to retention because your data usage is not highly diverse.
    • The overhead of implementing multiple retention categories might not be warranted yet.

In short, if you maintain a straightforward environment and your leadership sees no pressing issues with data retention, organisation-level policy awareness might suffice. However, for many UK public sector bodies, data sprawl and diverse workloads can quickly complicate retention, making manual approaches risky.

How to do better

Below are rapidly actionable steps to strengthen your organisational policy awareness and transition toward more robust management:

  1. Map Policy to Actual Cloud Storage

  2. Implement Basic Lifecycle Rules for Key Data Types

  3. Offer Practical Guidelines

    • Simplify your policy into short, scenario-based instructions. For instance:
      • “Project data that includes personal information must be kept for 2 years, then deleted.”
      • “No indefinite retention without approval from Data Protection Officer.”
    • Make these guidelines easily accessible (intranet page, project templates).

  4. Encourage Regular Self-Checks

  5. Align with Stakeholders

    • Brief senior leadership, legal teams, and information governance officers on any proposed changes or automation.
    • Gains their support by showing how these improvements reduce compliance risk and free up unnecessary storage costs.

By proactively mapping retention policies to actual data, implementing simple lifecycle rules, and guiding teams with clear, scenario-based instructions, you reinforce “Organisation-Level Policy Awareness” with tangible, enforceable practices.

Compliance Attestation by Projects: Projects and programs are not only aware but also required to formally attest their compliance with the data retention policies.

How to determine if this good enough

In this stage, each project/program must explicitly confirm they follow the retention rules. This might happen through project gating, sign-offs, or periodic reviews. You can consider it “good enough” if:

  1. Documented Accountability

    • Each project lead or manager signs a statement or includes a section in project documentation confirming adherence to the retention schedule.
    • This accountability often fosters better data hygiene.

  2. Compliance Embedded in Project Lifecycle

    • When new projects or services start, part of the onboarding includes discussing data retention needs.
    • Projects are less likely to “slip” on retention because they must address it at key milestones.

  3. Reduced Risk of Oversight

    • If an audit occurs, you can point to each project’s attestation as evidence of compliance.
    • This stage often prevents ad hoc or “forgotten” data sets from persisting indefinitely.

However, attestation can be superficial if not backed by validation or partial audits. Teams might sign off on compliance but still store data in ways that violate policy. As data footprints grow, manual attestations can fail to catch hidden or newly spun-up environments.

How to do better

Below are rapidly actionable ways to ensure attestations translate to real adherence:

  1. Incorporate Retention Audits into CI/CD

  2. Spot-Check Attestations with Periodic Scans

  3. Centralise Retention Documentation

    • Instead of scattered project documents, maintain a central registry or dashboard capturing:
      • Project name, data types, retention period, date of last attestation.
    • Provide read access to compliance and governance staff, ensuring quick oversight.

  4. Link Attestation to Funding or Approvals

    • For large programmes, make data retention compliance a prerequisite for budget release or major go/no-go decisions.
    • This creates a strong incentive to maintain correct lifecycle settings.

  5. Short Mandatory Training

    • Provide teams a bite-sized eLearning or workshop on how to configure retention in their chosen cloud environment.
    • This ensures they know the practical steps needed, so attestation isn’t just paperwork.

By coupling attestation with actual configuration checks, spot audits, centralised documentation, and relevant training, you boost confidence that claims of compliance match reality.

Regular Audits and Reviews: Data retention practices are periodically audited and reviewed for compliance, with findings addressed through action plans.

How to determine if this good enough

Once regular audits and reviews are in place, your organisation systematically verifies whether teams are adhering to the mandated retention policies. This can be “good enough” if:

  1. Scheduled, Transparent Audits

    • Every quarter or half-year, a designated group (e.g., an internal compliance team) or external auditor reviews data lifecycle settings, actual usage, and retention logs.

  2. Actionable Findings

    • Audit outcomes lead to real change—if a project is over-retaining or missing a lifecycle rule, they must fix it promptly, with a follow-up check.

  3. Reduction in Non-Compliance Over Time

    • Each review cycle sees fewer repeated issues or new violations, indicating the process is effective.

  4. Support from Leadership

    • Senior leadership or governance boards take these findings seriously, dedicating resources to address them.

If your audits reveal minimal breaches and the cycle of reporting → fixing → re-checking runs smoothly, you might meet the operational needs of most public sector compliance frameworks. However, as data volumes scale, purely manual or semi-annual checks may miss real-time issues, leading to potential non-compliance between audits.

How to do better

Below are rapidly actionable ways to strengthen your audit and review process:

  1. Adopt Automated Compliance Dashboards

  2. Include Retention in Security Scans

  3. Track Action Plans to Closure

    • Use a centralised ticketing or workflow tool (e.g., Jira, ServiceNow) to capture audit findings, track remediation, and confirm sign-off.
    • Tag each ticket with “Data Retention Issue” for easy reporting and trend analysis.

  4. Publish Trends and Success Metrics

    • Show leadership the quarterly or monthly improvement in compliance percentage.
    • Celebrating zero major findings in a review cycle fosters a positive compliance culture and encourages teams to keep up the good work.

  5. Integrate with Other Governance Reviews

    • Data retention checks can be coupled with data security, privacy, or cost reviews.
    • This holistic approach ensures teams address multiple dimensions of good data stewardship simultaneously.

By automating aspects of the review process, embedding retention checks into security tools, and systematically remediating findings, you evolve from static cyclical audits to a dynamic, ongoing compliance posture.

Inclusion in Risk Management: Edge cases and exceptions in data retention are specifically identified and managed within the organisation’s risk register.

How to determine if this good enough

At this stage, your organisation recognises that not all data fits neatly into standard retention policies. Some sensitive projects or legal hold scenarios might require exceptions. You might be “good enough” if:

  1. Risk Awareness

    • You systematically capture exceptions—like extended retention for litigation or indefinite archiving for historical records—within your official risk register.

  2. Clear Exception Processes

    • Teams that need longer or shorter retention follow a documented procedure, including justification and sign-off from legal or governance staff.

  3. Risk-Based Decision Making

    • Leadership reviews these exceptions periodically and weighs the potential risks (e.g., data breach, cost overhead, privacy concerns) against the need for extended retention.

  4. Traceable Accountability

    • Each exception has an owner who ensures compliance with any additional safeguards (e.g., encryption, restricted access).

Such a model keeps compliance tight, as unusual retention cases are formally recognised and managed. Still, some organisations lack robust automation or real-time checks that link risk registers to actual data settings, leaving room for human error.

How to do better

Below are rapidly actionable ways to embed retention exceptions deeper into risk management:

  1. Automate Exception Labelling and Monitoring

  2. Set Time-Bound Exceptions

    • Rarely should exceptions be indefinite. Include an “exception end date” in your risk register.
    • Use cloud scheduling or lifecycle policies to revisit after that date:
      • E.g., if an exception ends in 1 year, revert to normal retention automatically unless renewed.

  3. Enhance Risk Register Integration

    • Link risk items to your data inventory or data catalog so you can quickly see which resources are covered by the exception.
    • Tools like ServiceNow, Jira, or custom risk management solutions can cross-reference cloud resource IDs or labels.

  4. Reevaluate Exception Cases in Each Audit

    • Incorporate exception checks into your regular data retention audits:
      • Confirm the exception is still valid and authorised.
      • If it’s no longer needed, remove it and revert to standard retention policies.

  5. Leverage Encryption or Extra Security for Exceptions

By systematically capturing exceptions as risks, labeling them in cloud resources, setting expiry dates, and ensuring periodic review, your exceptions process remains controlled rather than a loophole. This approach mitigates the dangers of indefinite data hoarding and supports robust risk governance.

Automated Enforcement with Cloud Tools: Data retention is actively monitored and enforced using native cloud services and tools, ensuring adherence to policies through automation.

How to determine if this good enough

In this final, mature stage, your organisation uses automation to continuously track, enforce, and remediate data retention policies across all environments. It’s generally considered “good enough” if:

  1. Policy-as-Code

    • Retention rules are embedded in your Infrastructure as Code templates or pipelines. When new data storage is provisioned, the lifecycle or retention policy is automatically set.

  2. Real-Time or Near Real-Time Enforcement

    • If a project forgets to configure lifecycle rules or tries to extend retention beyond the allowed maximum, an automated policy corrects it or triggers an alert.

  3. Central Visibility

    • A dashboard shows the overall compliance posture in near-real-time, flagging exceptions or misconfigurations.
    • Governance teams can quickly drill into any resource that violates the standard.

  4. Minimal Manual Intervention

    • Staff rarely need to manually fix retention settings; automation handles the majority of routine tasks.
    • Audits confirm a high compliance rate, with issues addressed rapidly.

Although this represents a best-practice scenario, continuous improvements arise as new cloud services emerge or policy requirements change. Ongoing refinement ensures your automated approach stays aligned with departmental guidelines, security mandates, and potential changes in UK public sector data legislation.

How to do better

Even at the top maturity level, here are rapidly actionable ways to refine your automated enforcement:

  1. Deepen Integration with Data Catalog

  2. Leverage Event-Driven Remediation

  3. Expand to All Data Storage Services

  4. Adopt Predictive Monitoring for Storage Growth

  5. Utilise Predictive Analytics for Data Growth and Anomaly Detection

  6. Continuously Update Policies for New Data Types

    • As your department adopts new AI workloads, IoT sensor data, or unstructured media, confirm your automated retention tools can handle these new data flows.
    • Keep stakeholder alignment: if legislation changes (e.g., new FOI or data privacy rules), swiftly update your policy-as-code approach.

By aligning your advanced automation with data classification, extending coverage to all storage services, and employing event-driven remediation, you maintain an agile, reliable data retention program that rapidly adapts to technology or policy shifts. This ensures your UK public sector organisation upholds compliance, minimises data sprawl, and demonstrates best-in-class stewardship of public data.

Keep doing what you’re doing, and consider documenting or blogging about your journey to automated data retention enforcement. Submit pull requests to this guidance or share your success stories with the broader UK public sector community to help others achieve similarly robust data retention practices.

Governance

How does the shared responsibility model influence your organisation's approach to cloud consumption?

Minimal Consideration of Shared Responsibility: The shared responsibility model is not a primary factor in cloud consumption decisions, often leading to misunderstandings or gaps in responsibility.

How to determine if this good enough

When an organisation minimally accounts for the shared responsibility model, it often treats cloud services like a traditional outsourcing arrangement, assuming the provider handles most (or all) tasks. This might be considered “good enough” if:

  1. Limited Complexity or Strictly Managed Services

    • You consume only highly managed or software-as-a-service (SaaS) solutions, so the cloud vendor’s scope is broad, and your responsibilities are minimal.
    • In such cases, misunderstandings about lower-level responsibilities might not immediately cause problems.

  2. Small Scale or Low-Risk Workloads

    • You deploy minor pilot projects or non-sensitive data with minimal security or compliance overhead.
    • The cost and effort of clarifying responsibilities could feel disproportionate.

  3. Short-Term or Experimental Cloud Usage

    • You might be running proof-of-concepts or test environments that you can shut down quickly if issues arise.
    • If a gap in responsibility surfaces, it may not significantly impact operations.

However, as soon as you scale up, handle sensitive information, or rely on the cloud for critical services, ignoring the shared responsibility model becomes risky. For most UK public sector bodies, data security, compliance, and operational continuity are paramount—overlooking even a small portion of your obligations can lead to non-compliance or service disruptions.

How to do better

Below are rapidly actionable steps to move beyond minimal consideration of shared responsibilities:

  1. Identify Your Specific Obligations

  2. Apply Basic Tagging for Ownership

  3. Conduct a Simple Risk Assessment

    • Walk through a typical scenario (e.g., security incident or downtime) and identify who would act under the current arrangement.
    • Document any gaps (e.g., “We assumed the vendor patches the OS, but it’s actually an IaaS solution so we must do it ourselves.”) and address them promptly.

  4. Raise Awareness with a Short Internal Briefing

    • Present the shared responsibility model in a simple slide deck or lunch-and-learn:
      • Emphasize how it differs from on-prem or typical outsourcing.
      • Show real examples of misconfigurations that occurred because teams weren’t aware of their portion of responsibility.

  5. Involve Governance or Compliance Officers

    • Ensure your information governance team or compliance officer sees the model. They can help flag missing responsibilities, especially around data protection (UK GDPR) or official classification levels.
    • This can prevent future misunderstandings.

By clarifying essential tasks, assigning explicit ownership, and performing a quick risk assessment, you proactively plug the biggest gaps that come from ignoring the shared responsibility model.

Basic Awareness of Shared Responsibilities: There is a basic understanding of the model, but it’s not systematically applied or deeply understood across the organisation.

How to determine if this good enough

At this stage, your teams recognise that some aspects of security, patching, and compliance belong to you and others fall to the cloud provider. You might see this as “good enough” if:

  1. General Understanding Among Key Staff

    • Cloud architects, security leads, or DevOps teams can articulate the main points of the shared responsibility model.
    • They know the difference between SaaS, PaaS, and IaaS responsibilities.

  2. Minimal Incidents

    • You’ve not encountered major operational issues or compliance failures that trace back to confusion over who handles what.
    • Day-to-day tasks (e.g., OS patches, DB backups) proceed smoothly in most cases.

  3. No Large, Complex Workloads

    • If your usage is still relatively simple or in early phases, you might not need a fully systematic approach yet.

However, as soon as your environment grows or you onboard new teams or more complex solutions, “basic awareness” can be insufficient. If you rely on an ad hoc approach, you risk missing certain obligations (like security event monitoring or identity governance) and undermining consistent compliance.

How to do better

Here are rapidly actionable ways to convert basic awareness into structured alignment:

  1. Develop a Clear Responsibilities Matrix

    • Create a simple spreadsheet or diagram that outlines specific responsibilities for each service model (IaaS, PaaS, SaaS). For example:
      • “Networking configuration: Cloud vendor is responsible for physical network security; we handle firewall rules.”
      • “VM patching: We handle OS patches for IaaS; vendor handles it for managed PaaS.”
    • Share this matrix with all relevant teams—developers, ops, security, compliance.

  2. Embed Responsibility Checks in CI/CD

  3. Set Up Basic Compliance Rules

  4. Create a Minimum Standards Document

    • Summarise “We do X, vendor does Y” in a concise, 1- or 2-page reference for new hires, project leads, or procurement teams.
    • This helps each team swiftly verify if they’re meeting their obligations.

  5. Schedule Regular (Bi-Annual) Awareness Sessions

    • As new people join or existing staff shift roles, re-run an internal training on the shared responsibility model.
    • This ensures knowledge doesn’t degrade over time.

By formalising the understanding into documented responsibilities, embedding checks in your workflows, and reinforcing compliance rules, you strengthen your posture beyond mere awareness and toward consistent application across teams.

Informed Decision-Making Based on Shared Responsibilities: Decisions regarding cloud consumption are informed by the shared responsibility model, ensuring a clearer understanding of the division of responsibilities.

How to determine if this good enough

At this level, your organisation actively references the shared responsibility model when selecting, deploying, or scaling cloud services. You might consider this approach “good enough” if:

  1. Consistent Inclusion in Architecture and Procurement

    • Whenever a new application is planned, an architecture review clarifies who will handle patching, logging, network security, etc.
    • The procurement or project scoping includes the vendor’s responsibilities vs. yours, documented in service agreements.

  2. Reduced Misconfigurations

    • You see fewer incidents caused by someone assuming “the vendor handles it.”
    • Teams rarely have to scramble for post-deployment fixes related to neglected responsibilities.

  3. Cross-Functional Alignment

    • Security, DevOps, finance, and governance teams share the same interpretation of the model, preventing blame shifts or confusion.

  4. Auditable Evidence

    • If challenged by an internal or external auditor, you can present decision logs or architecture documents showing how you accounted for each aspect of shared responsibility.

If your cloud consumption decisions reliably incorporate these checks and remain transparent to all stakeholders, you might meet day-to-day operational needs. Still, you can enhance the process by making it even more strategic, with regular updates and risk-based evaluations.

How to do better

Below are rapidly actionable improvements to reinforce your informed decision-making:

  1. Adopt a “Responsibility Checklist” in Every Project Kickoff

  2. Integrate with Governance Boards or Change Advisory Boards (CAB)

    • Whenever a major cloud solution is proposed, the governance board ensures the shared responsibility breakdown is explicit.
    • This formal gate fosters consistent compliance with your model.

  3. Track “Responsibility Gaps” in Risk Registers

    • If you discover any mismatch—like you thought the vendor handled container OS patching, but it’s actually your job—log it in your risk register until resolved.
    • This encourages a quick fix and ensures no gap remains unaddressed.

  4. Conduct Periodic “Mock Incident” Exercises

    • For key services, run a tabletop exercise or test scenario: e.g., a severe OS vulnerability or unexpected data leak.
    • Evaluate how well the team knows who must patch or respond. Document lessons learned to refine your decision-making process.

  5. Refine Cost Transparency

    • Show how responsibilities can affect cost:
      • If you’re using a fully managed database, you pay a premium but shift more patching or upgrades to the vendor.
      • If you choose IaaS, you do more patching but may see lower direct service charges.
    • Provide a quick cost/responsibility matrix so teams can weigh these trade-offs effectively.

By embedding the model into architecture reviews, governance boards, risk tracking, and cost analysis, you ensure each cloud decision is well-informed and widely understood across the organisation.

Strategic Integration of Shared Responsibility in Cloud Planning: The shared responsibility model is strategically integrated into cloud consumption planning, with regular assessments to ensure responsibilities are well-managed. Decisions to retain responsibilities in house are documented and shared with the cloud vendor.

How to determine if this good enough

At this stage, your organisation not only references shared responsibilities when building or buying new solutions, but actively uses them to shape strategic roadmaps and service-level agreements. You might see this as “good enough” if:

  1. Proactive Vendor Collaboration

    • You regularly discuss boundary responsibilities with the cloud provider, clarifying tasks that remain in-house and tasks the vendor can adopt.
    • Contract renewals or expansions include updates to these responsibilities if needed.

  2. Routine Audits on Allocation of Responsibilities

    • Perhaps every 6–12 months, you review how the model is working in practice—are vendor-managed responsibilities handled properly? Are your in-house tasks well-executed?

  3. Clear Documentation of In-House Retained Tasks

    • For tasks like specialised security controls, data classification, or unique compliance checks, you deliberately keep them in house. You note these exceptions in your governance or vendor communication logs.

  4. Enhanced Risk Management

    • The risk register or compliance logs show minimal “unknown responsibility” gaps, and there’s a structured process for addressing new or changing requirements.

If your cloud planning and vendor engagements revolve around the shared responsibility model, ensuring alignment at both strategic and operational levels, you might meet advanced governance requirements in the UK public sector. Still, you can deepen the approach to ensure ongoing optimisation of cost, performance, and compliance.

How to do better

Here are rapidly actionable ideas to refine your strategic integration:

  1. Formalise a “Shared Responsibility Roadmap”

    • Outline how your responsibilities may shift as you adopt new services or modernise apps:
      • E.g., “We plan to transition from self-managed DB to a fully managed service, shifting patching to the vendor by Q4.”
    • Maintain an updated doc or wiki, shared with vendor account managers if relevant.

  2. Implement Joint Incident-Response Protocols

  3. Regular Joint Reviews of SLAs and MoUs

    • MoU (Memorandum of Understanding) or contracts can explicitly reference responsibilities.
    • Revisit them at least annually to confirm they remain relevant, especially if the vendor introduces new features or if you adopt new compliance frameworks.

  4. Quantify Responsibility Impacts on Cost and Resource

    • Evaluate how shifting responsibilities (e.g., from IaaS to PaaS) reduces your operational overhead or risk while potentially increasing subscription fees.
    • This cost-benefit analysis should guide strategic decisions about which responsibilities to keep in house.

  5. Publish Internal Case Studies

    • Showcase a project that integrated the shared responsibility model successfully, explaining how it prevented major incidents or streamlined compliance.
    • This inspires other teams to replicate the approach.

By systematically planning your responsibilities roadmap, establishing joint incident protocols, and performing regular SLA reviews, you embed the shared responsibility model at the heart of your strategic cloud partnerships.

Critical Factor in Cloud Consumption and Value Assessment: The shared responsibility model is central to all decision-making regarding cloud consumption. It’s regularly revisited to assess value for money and optimise the division of responsibilities with the cloud vendor.

How to determine if this good enough

This final maturity level sees the shared responsibility model as a cornerstone of your cloud strategy:

  1. Continuous Governance and Optimisation

    • Teams treat shared responsibilities as a dynamic factor—constantly reviewing how tasks, risk, or cost can be best allocated between you and the vendor.
    • It’s integrated with your architecture, security, compliance, and financial planning.

  2. Live Feedback Loops

    • When new cloud features or vendor service upgrades appear, you evaluate if shifting responsibilities (e.g., to a new managed service) is beneficial or if continuing in-house control is more cost-effective or necessary for compliance.

  3. Frequent Collaboration with Vendor

    • You hold regular “architecture alignment” or “service optimisation” sessions with the cloud provider, ensuring your responsibilities remain well-balanced as your environment evolves.

  4. High Transparency and Minimal Surprises

    • Incidents or compliance checks rarely expose unknown gaps.
    • You have robust confidence in your risk management, cost forecasting, and operational readiness.

If you operate at this level, you’re likely reaping the full benefit of cloud agility, cost optimisation, and compliance. Even so, continued vigilance is needed to adapt to new regulations, technology changes, or organisational shifts.

How to do better

Even at the pinnacle, there are actionable strategies to maintain and refine:

  1. Incorporate Real-Time Observability of Shared Responsibilities

  2. Conduct Regular Cost-Benefit Re-Evaluations

    • At least quarterly, re-check if shifting more responsibilities to vendor-managed solutions or retaining them in house remains the best approach:
      • Some tasks might become cheaper or more secure if the vendor has introduced an improved managed feature or a new region with stronger compliance credentials.
    • Document these findings for leadership to see the ROI of the chosen approach.

  3. Shape Best Practices Across the Public Sector

    • Share your advanced model with partner agencies, local councils, or central government departments.
    • Contribute to cross-government playbooks on cloud adoption, showing how the shared responsibility model fosters better outcomes.

  4. Combine Shared Responsibility Insights with Ongoing Cloud Transformation

    • If you’re running modernisation or digital transformation programs, embed the shared responsibility model into new microservices, container deployments, or serverless expansions.
    • Constantly question: “Where does the boundary lie, and is it cost-effective or compliance-aligned to shift it?”

  5. Prepare for Regulatory Changes

    • Monitor updates to UK data protection laws, the National Cyber Security Centre (NCSC) guidelines, or changes in vendor compliance certifications.
    • Adjust responsibilities quickly if new standards require a different approach (e.g., more encryption or different backup retention mandated by a new policy).

By ensuring real-time observability, frequent cost-benefit checks, sector-wide collaboration, and a readiness to pivot for regulatory shifts, you sustain a robust, adaptive shared responsibility model at the core of your cloud usage. This cements your organisation’s position as a leader in cost-effective, secure, and compliant public sector cloud adoption.

Keep doing what you’re doing, and consider sharing blog posts, case studies, or internal knowledge base articles on how your organisation integrates the shared responsibility model into cloud governance. Submit pull requests to this guidance or similar public sector best-practice repositories to help others learn from your success.

How does your organisation handle the creation and storage of build artifacts?

Ad-Hoc or Non-Existent Artifact Management: Build artifacts are not systematically managed; code and configurations are often edited live on servers.

How to determine if this good enough

In this stage, your organisation lacks formal processes to create or store build artifacts. You might find this approach “good enough” if:

  1. Limited or Non-Critical Services

    • You run only small-scale or temporary services where changes can be handled manually, and downtime or rollback is not a major concern.

  2. Purely Experimental or Low-Sensitivity

    • The data or systems you manage are not subject to stringent public sector regulations or sensitivity classifications (e.g., prototyping labs, dev/test sandboxes).

  3. Single-Person or Very Small Team

    • A single staff member manages everything, so there’s minimal confusion about versions or changes.
    • The risk of accidental overwrites or lost code is recognised but considered low priority.

However, even small teams can face confusion if code is edited live on servers, making it hard to replicate environments or roll back changes. For most UK public sector needs—especially with compliance or audit pressures—lack of artifact management eventually becomes problematic.

How to do better

Below are rapidly actionable steps to move away from ad-hoc methods:

  1. Introduce a Basic CI/CD Pipeline

  2. Ensure Everything Is in Version Control

  3. Create a Shared Storage for Build Outputs

  4. Document Basic Rollback Steps

    • At a minimum, define how to revert a server or application if a live edit breaks something:
      • Write a short rollback procedure referencing the last known working code in version control.
    • This ensures you’re not stuck with manual edits you can’t undo.

  5. Educate the Team

    • Explain the risks of live server edits in short training sessions:
      • Potential compliance violations if changes are not auditable.
      • Difficulty diagnosing or rolling back production issues.

By adopting minimal CI/CD, storing artifacts in a shared location, and referencing everything in version control, you reduce chaos and set a foundation for more robust artifact management.

Environment-Specific Rebuilds: Artifacts are rebuilt in each environment, leading to potential inconsistencies and inefficiencies.

How to determine if this good enough

In this scenario, your organisation has some automation but rebuilds the software in dev, test, and production separately. You might see this as “good enough” if:

  1. Low Risk of Version Drift

    • The codebase and dependencies rarely change, or you have a small dev team that carefully ensures each environment has identical build instructions.

  2. Limited Formality

    • If you’re still in early stages or running small services, you might tolerate the occasional mismatch between environments.

  3. Few Dependencies

    • If your project has very few external libraries or minimal complexity, environment-specific rebuilds don’t cause many issues.

However, environment-specific rebuilds can cause subtle differences, making debugging or compliance audits more complex—especially in the UK public sector, where consistent deployments are often required to ensure stable and secure services.

How to do better

Below are rapidly actionable strategies:

  1. Centralise Your Build Once

  2. Define a Consistent Build Container

    • If you want complete reproducibility:
      • Use a Docker image as your build environment (e.g., pinned versions of compilers, frameworks).
      • Keep that Docker image in your artifact registry so each new build uses the same environment.

  3. Implement Version or Commit Hash Tagging

    • Tag the artifact with a version or Git commit hash. Each environment references the same exact build (like “my-service:build-1234”).
    • This eliminates guesswork about which code made it to production vs. test.

  4. Apply Simple Promotion Strategies

    • Instead of rebuilding, you “promote” the tested artifact from dev to test to production:
      • Mark the artifact as “passed QA tests” or “passed security scan,” so you have a clear chain of trust.
    • This approach improves reliability and shortens lead times.

  5. Create Basic Documentation

    • Summarise the difference between “build once, deploy many” and “build in each environment.”
    • Show management how consistent builds reduce risk and effort.

By consolidating the build process, storing a single artifact per version, and promoting that same artifact across environments, you achieve consistency and reduce the risk of environment drift.

Basic Artifact Storage with Version Control: Build artifacts are stored, possibly with version control, but without strong emphasis on immutability or security measures.

How to determine if this good enough

Here, your organisation has progressed to storing build artifacts in a central place, often with versioning. This can be considered “good enough” if:

  1. You Can Reproduce Past Builds

    • You label or tag artifacts, so retrieving an older release is relatively straightforward.
    • This covers basic audit or rollback needs.

  2. Moderate Risk Tolerance

    • You handle data or applications that don’t require the highest security or immutability (e.g., citizen-facing website with low data sensitivity).
    • Rarely face formal audits demanding cryptographic integrity checks.

  3. No Enforcement of Immutability

    • Your system might allow artifact overwrites or deletions, but your teams rarely abuse this.
    • The risk of malicious or accidental tampering is minimal under current conditions.

While this is a decent midpoint, the lack of immutability or strong security measures can pose challenges if you must prove the authenticity or integrity of a specific artifact, especially in regulated public sector contexts.

How to do better

Here are rapidly actionable enhancements:

  1. Adopt Write-Once-Read-Many (WORM) or Immutable Storage

  2. Set Up Access Controls and Auditing

  3. Enforce In-House or Managed Build Numbering Standards

    • Decide how you version artifacts (e.g., semver, build number, git commit) to ensure consistent tracking across repos.
    • This practice reduces confusion when dev/test teams talk about a specific build.

  4. Extend to Container Images or Package Repositories

  5. Introduce Minimal Integrity Checks

    • Even if you don’t have full cryptographic signatures, consider generating checksums (e.g., SHA256) for each artifact to detect accidental corruption.

By using immutable storage, controlling access, and standardising versioning, you strengthen artifact reliability and traceability without overwhelming your current processes.

Pinned Dependencies with Cryptographic Verification: All dependencies in build artifacts are tightly pinned to specific versions, with cryptographic signing or hashes to ensure integrity.

How to determine if this good enough

Here, your build pipelines ensure that not only your application code but also every library or dependency is pinned to a specific version, and you verify these via cryptographic means. You might consider this approach “good enough” if:

  1. High Confidence in Artifact Integrity

    • You can guarantee the code and libraries used in staging match those in production.
    • Security incidents involving compromised packages are less likely to slip through.

  2. Robust Supply Chain Security

    • Attackers or misconfigured servers have a harder time injecting malicious code or outdated dependencies.
    • This is crucial for UK public sector services handling personal or sensitive data.

  3. Comprehensive Logging

    • You track which pinned versions (e.g., libraryA@v2.3.1) were used for each build.
    • This improves forensic investigations if a vulnerability is discovered later.

  4. Controlled Complexity

    • Pinning and verifying dependencies might slow down upgrades or require more DevOps effort, but your teams accept it as a valuable security measure.

If you rely on pinned dependencies and cryptographic verification, you’re covering a big portion of software supply chain risks. However, you might still enhance final artifact immutability or align with advanced threat detection in your build process.

How to do better

Below are rapidly actionable improvements:

  1. Leverage Vendor Tools for Dependency Scanning

  2. Sign Your Artifacts

  3. Adopt a “Bill of Materials” (SBOM)

    • Generate a Software Bill of Materials for each build, listing all dependencies and their checksums:
      • This clarifies exactly which libraries or frameworks were used, crucial for quick vulnerability response.

  4. Enforce Minimal Versions or Patch Levels

    • If a library has a known CVE, your pipeline rejects builds that rely on that version.
    • This ensures you don’t accidentally revert to vulnerable dependencies.

  5. Combine with Immutable Storage

    • If you haven’t already, store these pinned, verified artifacts in a write-once or strongly controlled location.
    • This ensures no tampering after you sign or hash them.

By scanning for vulnerabilities, signing artifacts, using SBOMs, and enforcing patch-level policies, you secure your supply chain and provide strong assurance of artifact integrity.

Immutable, Signed Artifacts with Audit-Ready Storage: Immutable build artifacts are created and cryptographically signed, especially for production. All artifacts are stored in immutable storage for a defined period for audit purposes, with a clear process to recreate environments for thorough audits or criminal investigations.

How to determine if this good enough

At this final stage, your organisation has robust, end-to-end artifact management. You consider it “good enough” if:

  1. Full Immutability and Cryptographic Assurance

    • Every production artifact is sealed (signed), ensuring no one can alter it post-build.
    • You store these artifacts in a tamper-proof or strongly controlled environment (e.g., WORM storage).

  2. Long-Term Retention for Audits

    • You can quickly produce the exact code, libraries, and container images used in production months or years ago, aligning with public sector mandates (e.g., 2+ years or more if relevant).

  3. Ability to Recreate Environments

    • If an audit or legal inquiry arises, you can spin up the environment from these artifacts to demonstrate what was running at any point in time.

  4. Compliance with Regulatory/Criminal Investigation Standards

    • If part of your remit includes potential criminal investigations (e.g., digital forensics for certain public sector services), the chain of custody for your artifacts is guaranteed.

If you meet these conditions, you are at a high maturity level, ensuring minimal risk of supply chain attacks, compliance failures, or untraceable changes. Periodic revalidations keep your process evolving alongside new threats or technologies.

How to do better

Even at this pinnacle, there are actionable ways to refine:

  1. Automate Artifact Verification on Deployment

  2. Embed Forensic Analysis Hooks

    • Provide metadata in logs (e.g., commit hashes, SBOM references) so if an incident occurs, security teams can quickly retrieve the relevant artifact.
    • This reduces incident response time.

  3. Regularly Test Restoration Scenarios

    • Conduct a “forensic reenactment” once or twice a year:
      • Attempt to reconstruct an environment from your stored artifacts.
      • Check if you can seamlessly spin up an older version with pinned dependencies and configurations.
    • This ensures the system works under real conditions, not just theory.

  4. Apply Multi-Factor Access Control

  5. Participate in Industry or Government Communities

    • As you lead in artifact management maturity, share best practices with other public sector bodies or cross-governmental security groups.
    • Encourage consistent auditing and artifact immutability standards across local councils, departmental agencies, or NHS trusts.

By verifying artifacts on each deployment, maintaining robust forensic readiness, testing restoration scenarios, and securing signing keys with HSMs or advanced controls, you perpetually refine your processes. This ensures unwavering trust and compliance in your build pipeline, even under rigorous UK public sector scrutiny.

Keep doing what you’re doing, and consider sharing case studies or best-practice guides. Submit pull requests to this guidance or other UK public sector repositories to help others learn from your advanced artifact management journey.

How does your organisation manage and update access policies and controls, and how are these changes communicated?

Ad-Hoc Policy Management and Inconsistent Application: Policies are not formally defined; decisions are based on individual opinion or past experience. Policies are not published, access controls are inconsistently applied, and exemptions are often granted without follow-up.

How to determine if this good enough

When access policies are managed in an ad-hoc manner:

  1. Small Scale, Low Risk

    • You may be a small team with limited scope. If you only handle low-sensitivity or non-critical information, an ad-hoc approach might not have caused major issues yet.

  2. Minimal Regulatory Pressures

    • If you’re in a part of the public sector not subject to specific frameworks (e.g., ISO 27001, Government Security Classifications), you might feel less pressure to formalise policies.

  3. Very Basic or Temporary Environment

    • You could be running short-lived experiments or pilot projects with no extended lifespans, so detailed policy management feels excessive.

However, this level of informality quickly becomes a liability, especially in the UK public sector. Requirements for compliance, security best practices, and data protection (including UK GDPR considerations) often demand a more structured approach. Inconsistent or undocumented policies can lead to significant vulnerability and confusion when staff rotates or scales up.

How to do better

Below are rapidly actionable steps to move away from ad-hoc management:

  1. Begin a Simple Policy Definition

    • Draft a one-page document outlining baseline access rules (e.g., “Least privilege,” “Need to know”).
    • Reference relevant UK government guidance on access controls or consult your departmental policy docs.

  2. Centralise Identity and Access

  3. Record Exemptions in a Simple Tracker

    • If you must grant an ad-hoc exception, log it in a basic spreadsheet or ticket system:
      • Who was granted the exception?
      • Why?
      • When will it be revisited or revoked?

  4. Define at Least One “Review Step”

    • If someone wants new permissions, ensure a second person or a small group must approve the request.
    • This adds minimal overhead but prevents hasty over-permissioning.

  5. Communicate the New Basic Policy

    • Email a short notice to your team, or host a 15-minute briefing.
    • Emphasize that all new access requests must align with the minimal policy.

By introducing a baseline policy, centralising identity management, tracking exceptions, and implementing a simple approval step, you achieve immediate improvements and lay the groundwork for more robust policy governance.

Basic Policy Documentation with Some Communication: Access policies are documented, but updates and their communication are irregular. There is a lack of a systematic approach to applying and communicating policy changes.

How to determine if this good enough

At this stage, you have a documented policy—likely created once and updated occasionally. You might consider it “good enough” if:

  1. Visibility of the Policy

    • Stakeholders can find it in a shared repository, intranet, or file system.
    • There’s a moderate awareness among staff.

  2. Some Level of Consistency

    • Access controls typically align with the documented policy, though exceptions may go unnoticed.
    • Projects mostly follow the policy, but not always systematically.

  3. Few or Minor Incidents

    • You haven’t encountered major security or compliance issues from poor access control.
    • Audits might find some improvement areas but no critical failings.

However, a lack of regular updates or structured communication means staff may be uninformed when changes occur. Additionally, bigger or cross-department projects can misinterpret or fail to adopt these policies if not regularly reinforced.

How to do better

Here are rapidly actionable enhancements:

  1. Schedule Regular Policy Updates

    • Commit to revisiting policies at least annually or semi-annually, and each time there’s a major change (e.g., new compliance requirement).
    • Add a reminder to your calendar or project board for a policy review session.

  2. Establish a Basic Change Log

  3. Use Consistent Communication Channels

    • If you have an organisational Slack, Teams, or intranet, create a #policy-updates channel (or equivalent) to announce changes.
    • Summarise the key differences in plain language.

  4. Apply or Update an RBAC Model

  5. Create a Briefing Deck

    • Summarise the policy in fewer than 10 slides or 1–2 pages, so teams quickly grasp their obligations.
    • Present it in your next all-hands or departmental meeting.

By versioning your policy documents, scheduling updates, and communicating changes through consistent channels, you ensure staff remain aligned with the policy’s intent and scope, even as it evolves.

Regular Policy Reviews with Formal Communication Processes: Policies are regularly reviewed and updated, with formal processes for communicating changes to relevant stakeholders, though the process may not be fully transparent or collaborative.

How to determine if this good enough

You conduct reviews on a known schedule (e.g., quarterly or bi-annually), and policy updates follow a documented communication plan. This might be “good enough” if:

  1. Predictable Review Cycles

    • Teams know when to expect policy changes and how to provide feedback.
    • Surprises or sudden changes are less common.

  2. Structured Communication Path

    • You send out formal emails, intranet announcements, or notifications to staff and relevant teams whenever changes occur.
    • The updates typically highlight “what changed” and “why.”

  3. Most Stakeholders Are Informed

    • While not fully collaborative, key roles (like security, DevOps, compliance leads) always see updates promptly.
    • Regular staff might be passively informed or updated in team briefings.

  4. Less Chaos in Access Controls

    • The process reduces ad-hoc or unauthorised changes.
    • Audits show improvements in the consistency of applied policies.

If your approach largely prevents confusion or major policy gaps, you’ve reached a good operational level. However, for advanced alignment—especially for larger or cross-government programs—you may want more transparency and active collaboration.

How to do better

Below are rapidly actionable ways to refine:

  1. Introduce a “Policy Advisory Group”

    • Involve representatives from different teams (security, compliance, operations, major app owners).
    • They review proposed changes before final approval, fostering collaboration and broader buy-in.

  2. Leverage Automated Policy Tools

  3. Conduct Impact Assessments

    • Each time a policy update is proposed, share an “impact summary” so teams know if they must adjust access roles, add new logging, or change their workflows.

  4. Record Meeting Minutes or Summaries

    • Publish a short summary of each policy review session.
    • This allows staff who couldn’t attend to remain informed and fosters more transparency.

  5. Add a Feedback Loop

    • Let staff submit policy improvement suggestions via an online form or an email address.
    • Review these suggestions in each policy cycle, acknowledging them in announcements.

By establishing a policy advisory group, using automated enforcement, sharing impact assessments, and keeping transparent documentation, you enhance collaboration and understanding around policy changes.

Integrated Policy Management with Stakeholder Engagement: Policy updates are managed through an integrated process involving key stakeholders. Changes are communicated effectively, ensuring clear understanding across the organisation.

How to determine if this good enough

In this scenario, the policy process is well-structured and inclusive:

  1. Collaborative Policy Updates

    • Stakeholders from various departments (security, finance, operations, legal, etc.) collaborate to shape and approve changes.

  2. Clear, Consistent Communication

    • Staff know exactly where to look for upcoming policy changes, final decisions, and rationale.
    • The policy is more likely to be understood and adopted, reducing friction.

  3. Fewer Exemptions or Gaps

    • Because the right people are involved from the start, there are fewer last-minute exceptions.
    • Auditors typically find the system robust and responsive to new requirements.

  4. Measured Efficiency

    • While more complex to coordinate, the integrated process might still be streamlined to avoid bureaucratic delays.

If your integrated approach ensures strong buy-in and minimal policy confusion, you are likely meeting the needs of most public sector compliance standards. You may still evolve by embracing a code-based approach or embedding continuous testing.

How to do better

Below are rapidly actionable strategies:

  1. Use Version Control for Policy and Automated Testing

  2. Schedule Interactive Workshops

    • Quarterly or monthly policy workshops enable direct Q&A and early feedback on proposed changes, preventing surprises.

  3. Implement a Self-Service Portal or Dashboard

  4. Link Policy Changes to Organisational Goals

    • For each update, clearly state how it supports:
      • Security improvements (reducing potential data breaches).
      • Compliance with UK data protection or government classification requirements.
      • Operational efficiency or cost savings.

  5. Establish Basic Metrics

    • E.g., measure “time to complete a policy change,” “number of exemptions requested,” or “incident rate attributed to policy confusion.”
    • Track these to demonstrate improvements over time.

By versioning policy code, conducting interactive workshops, providing self-service dashboards, and linking changes to tangible organisational goals, you reinforce a collaborative, integrated policy management culture.

Policy as Code with Transparent, Collaborative Updates: Policy intent and implementation are maintained in version control, accessible to all. The process for proposing updates is clear and well-understood, allowing for regular, transparent updates akin to software releases. Policies have testable side effects, ensuring clarity and comprehension.

How to determine if this good enough

At this top maturity level, policy management is treated like software development:

  1. Full Transparency and Collaboration

    • Anyone in the organisation (or designated roles) can propose, review, or comment on policy changes.
    • Policy changes pass through a formal PR (pull request) or code review process.

  2. Automated Testing or Validations

    • Updates to policy are tested—either by applying them in a staging environment or using policy-as-code testing frameworks.
    • This ensures changes do what they’re intended to do.

  3. Instant Visibility of Policy State

    • A central dashboard or repository shows the current “approved” policy version and any in-progress updates.
    • Historical records of every previous policy version are readily available.

  4. Regulatory Confidence

    • Auditors or compliance officers see an extremely robust, traceable approach.
    • Exemptions or special cases are handled via code-based merges or feature branches, ensuring full transparency.

If you meet these criteria, you’re likely an exemplar of policy governance within the UK public sector. Regular retrospectives can still uncover incremental improvements or expansions to new services or cross-department integrations.

How to do better

Below are rapidly actionable improvements, even at the highest level:

  1. Adopt Advanced Policy Testing Frameworks

  2. Create a Sandbox for Policy Experiments

    • Let staff propose changes in a “policy staging environment” or a set of test subscriptions/accounts/folders.
    • Automatic validation ensures no harmful or contradictory rules get merged into production.

  3. Automate Documentation Generation

  4. Extend Collaboration to Partner Agencies

    • If you work closely with other local authorities or health boards, consider sharing a portion of your policy code or best practices across organisations.
    • This fosters consistency and accelerates policy alignment.

  5. Perform Periodic “Policy Drills”

    • Similar to security incident drills, you can test large policy changes:
      • E.g., “We propose removing direct SSH access to all VMs” or “We require multi-factor authentication for every console user.”
    • Observe the process of review, merging, and rollout—this ensures your pipeline works under pressure.

By integrating advanced testing frameworks, using a sandbox approach, automating documentation, and sharing with partner agencies, you keep your policy-as-code approach dynamic and continuously improving, setting a standard for robust and transparent governance in the UK public sector.

Keep doing what you’re doing, and consider writing blog posts or internal knowledge base articles on your policy management journey. Submit pull requests to this guidance or similar public sector best-practice repositories to help others learn from your successful practices.

How does your organisation manage its cloud environment?

Manual Click-Ops as Required: Cloud management is performed manually as and when needed, without any systematic approach or automation.

How to determine if this good enough

Your organisation relies on the cloud provider’s GUIs or consoles to handle tasks, with individual admins making changes without formal processes or documentation. This might be “good enough” if:

  1. Small, Low-Risk Projects

    • You handle a small number of resources or have minimal production environments, and so far, issues have been manageable.

  2. Exploratory Phase

    • You’re testing new cloud services for proof-of-concept or pilot projects, with no immediate scaling needs.

  3. Limited Compliance Pressures

However, purely manual approaches risk misconfigurations, leftover resources, security oversights, and inconsistent environments. NIST SP 800-53 CM controls and NCSC best practices encourage structured management to reduce such risks.

How to do better

Runbooks and Playbooks

  1. Create Minimal Runbooks/Playbooks

  2. Ensure Accessibility & Security

  3. Enforce Update Discipline

    • Each time an admin modifies the environment, they must update the runbook.
    • Prevents drift where docs become irrelevant or untrusted.
Change Logs and Audit Logs

  1. Enable Cloud Provider Audit Logging

  2. Capture the “Why”

    • Maintain a short change log to record the rationale behind config changes:
      • Possibly a central wiki or a simple Slack channel for “cloud change announcements.”

  3. Plan Next Steps

    • Use these logs to identify repetitive tasks or areas ripe for automation in the near future.

By documenting runbooks/playbooks, ensuring logs are enabled and accessible, capturing rationale behind changes, and frequently updating your documentation, you reduce the risks tied to manual “click-ops” while preparing the groundwork for partial or full automation.

Documented Manual Click-Ops: Manual click-ops are used, but steps are documented. Operations may be tested in a similarly maintained non-production environment, though discrepancies likely exist between environments.

How to determine if this good enough

Your organisation documents step-by-step procedures for the cloud environment, with a test or staging environment that somewhat mirrors production. However, small differences frequently occur. It might be “good enough” if:

  1. Moderate Complexity

    • While you maintain a test environment, changes must still be repeated manually in production.

  2. Consistent, Though Manual

    • Admins do follow a standard doc for each operation, reducing accidental misconfigurations.

  3. Some Variation Tolerated

    • You can accommodate minor environment discrepancies that don’t cause severe issues.

However, manually repeating steps can lead to drift over time, especially if some updates never make it from test to production (or vice versa). NCSC operational resilience approaches and NIST SP 800-53 CM controls typically advocate more consistent, automated management to ensure parity across environments.

How to do better

Below are rapidly actionable improvements:

  1. Use Scripting for Repetitive Tasks

  2. Track Environment Differences

  3. Add Post-Deployment Verification

    • After each manual deployment, run a checklist or small script that verifies key resources are correct.

  4. Plan a Shift to Infrastructure-as-Code

  5. Initiate Basic Drift Detection

By partially automating recurring tasks, carefully recording environment discrepancies, verifying deployments, piloting Infrastructure-as-Code, and implementing drift checks, you mitigate errors and pave the way for more complete automation.

Semi-Automated with Some Scripting: Some aspects of cloud management are automated, possibly through scripting, but manual interventions are still common for complex tasks or configurations.

How to determine if this good enough

Your organisation uses scripts (e.g., Bash, Python, PowerShell) or partial IaC for routine tasks, while specialised or complex changes remain manual. This might be “good enough” if:

  1. Significant Time Savings Already

    • You see reduced misconfigurations for routine tasks (like creating instances or networks), but still handle complex or one-off scenarios manually.

  2. Mixed Skill Levels

    • Some staff confidently script or write IaC, others prefer manual steps, leading to a hybrid approach.

  3. Minor Environment Discrepancies

    • Since not all is automated, drift can occur but is less frequent.

You can further unify your scripts into a consistent pipeline or adopt a more complete Infrastructure-as-Code strategy. NCSC’s DevSecOps best practices and NIST SP 800-53 CM controls support extended automation for better security and consistency.

How to do better

Below are rapidly actionable ways to evolve from partial scripting:

  1. Expand Scripting to Complex Tasks

  2. Adopt an IaC Framework

  3. Introduce Basic CI/CD

  4. Set up a “Review & Approve” Process

  5. Leverage Cloud Vendor Tools

By incrementally automating complex changes, standardising on an IaC framework, establishing a basic CI/CD workflow, ensuring code reviews, and utilising vendor orchestration tools, you reduce your reliance on manual interventions and strengthen cloud environment consistency.

Highly Automated with Standardised Processes: Cloud management is largely automated with standardised processes across environments. Regular reviews and updates are made to ensure alignment with best practices.

How to determine if this good enough

Your organisation employs a robust Infrastructure-as-Code or automation-first approach, with minimal manual steps. This may be “good enough” if:

  1. Consistent Environments

    • Dev, test, and production are nearly identical, drastically reducing drift.

  2. Frequent Delivery & Minimal Incidents

  3. Adherence to Security & Compliance

To push further, you could adopt advanced drift detection, code-based policy enforcement, or real-time security scanning for each pipeline. NIST SP 800-137 for continuous monitoring and NCSC’s protective monitoring approaches might guide deeper expansions.

How to do better

Below are rapidly actionable ways to refine a highly automated approach:

  1. Implement Automatic Drift Remediation

  2. Incorporate Policy-as-Code

  3. Extend DevSecOps Tooling

    • e.g., scanning IaC templates for security issues, verifying recommended best practices in each pipeline step:
      • referencing NCSC’s secure developer guidelines or NIST SP 800-53 R5 for secure configurations.

  4. Perform Regular Architecture Reviews

    • With a high level of automation, a small monthly or quarterly session can keep IaC templates up to date with new cloud features or cost optimisation.

  5. Foster Cross-Department Knowledge Sharing

By enabling automatic drift remediation, implementing policy-as-code, enhancing DevSecOps pipeline checks, conducting periodic architecture reviews, and collaborating across agencies, you refine a strong foundation of standardised, highly automated processes for cloud management.

Fully Managed by Declarative Code with Drift Detection: Cloud management is fully automated and managed by declarative code. Continual automated drift detection is in place, with alerts for any deviations treated as significant incidents.

How to determine if this good enough

At this advanced stage, every resource is defined in code (e.g., Terraform, CloudFormation, Bicep, ARM templates, Deployment Manager, or other). The environment automatically reverts or alerts on changes outside of pipelines. Typically “good enough” if:

  1. Zero Manual Changes

    • All modifications go through code merges and CI/CD, preventing confusion or insecure ad-hoc changes.

  2. Instant Visibility

    • If drift occurs (someone clicked in the console or an unexpected event occurred), an alarm triggers, prompting immediate rollback or investigation.

  3. Rapid & Secure Deployments

    • Security, cost, and performance optimisations can be tested and deployed quickly without risk of untracked manual variations.

You can further refine HPC/AI ephemeral resources, cross-department pipeline sharing, or advanced policy-as-code with AI-based compliance. NCSC’s advanced DevSecOps or zero trust guidance and NIST SP 800-53 CM controls for automated configuration management encourage continuous iteration.

How to do better

Below are rapidly actionable methods to maximise a fully declarative, drift-detecting environment:

  1. Integrate Real-Time Security & Cost Checks

  2. Adopt Multi-Cloud or Hybrid Templates

    • If you operate across multiple clouds or on-prem, unify definitions in a single code base:

  3. Enhance Observability

  4. Foster a Culture of Peer Reviews

  5. Pursue Cross-Government Collaboration

    • If possible, share or open-source reusable modules or templates:

By adding real-time security and cost checks in your pipeline, adopting multi-cloud/hybrid IaC, enhancing observability, promoting peer reviews, and collaborating with other UK public sector bodies, you reinforce an already advanced, fully declarative environment with robust drift detection—ensuring secure, consistent, and efficient cloud management.

Keep doing what you’re doing, and consider publishing blog posts or making pull requests to share your approach to fully automated, code-based cloud management with drift detection. This knowledge can help other UK public sector organisations replicate your success under NCSC, NIST, and GOV.UK best-practice guidelines.

How is policy application and enforcement managed in your organisation?

No Policy Application: Policies are not actively applied within the organisation.

How to determine if this good enough

If policies are not actively applied, your organisation may still be at a very early or exploratory stage. You might perceive this as “good enough” if:

  1. No Critical or Sensitive Operations

    • You operate minimal or non-critical services, handling little to no sensitive data or regulated workloads.
    • There’s no immediate requirement (audit, compliance, security) pressing for formal policy usage.

  2. Limited Scale or Temporary Projects

    • Teams are small and can coordinate informally, or the entire environment is short-lived with minimal risk.

  3. No Internal or External Mandates

    • No formal rules require compliance with recognised governance frameworks (e.g., ISO 27001, NCSC Cloud Security Principles).
    • Organisational leadership has not mandated policy implementation.

However, as soon as you store personal, official, or sensitive data—or your environment becomes critical to a public service—lack of policy application typically leads to risk of misconfigurations, data leaks, or compliance failures.

How to do better

Below are rapidly actionable steps to start applying policies:

  1. Define a Minimal Baseline Policy

    • Begin by stating basic governance guidelines (e.g., “All user accounts must have multi-factor authentication,” “All data must be encrypted at rest”).
    • Publish this in a short doc or wiki, referencing relevant UK public sector best practices.

  2. Identify a Small Pilot Use Case

  3. Communicate the Policy

    • Alert your team that from now on, they must follow this minimal policy.
    • Provide quick references or instructions in your Slack/Teams channel or an intranet page.

  4. Log Exceptions

    • If someone must deviate from the baseline (e.g., a short-term test needing an exception), track it in a simple spreadsheet or ticket system.
    • This fosters accountability and sets the stage for incremental improvement.

By taking these initial steps—defining a baseline policy, piloting it, and communicating expectations—you move from “no policy application” toward a more controlled environment.

Policy Existence Without Enforcement: Policies exist but are not actively enforced or monitored.

How to determine if this good enough

Here, your organisation may have documented policies, but there is no real mechanism to ensure staff or systems comply. You might consider this “good enough” if:

  1. Policies Are Referenced, Not Mandatory

    • Teams consult them occasionally but can ignore them with minimal consequences.
    • Leadership or audits haven’t flagged major non-compliance issues—yet.

  2. Low Regulatory Pressure

    • You might not be heavily audited or regulated, so the absence of enforcement tools has not been problematic.

  3. Early in Maturity Journey

    • You wrote policies to set direction, but formal enforcement mechanisms aren’t established. You rely on staff cooperation.

Over time, lack of enforcement typically leads to inconsistent implementation and potential security or compliance gaps. The risk escalates with more complex or critical workloads.

How to do better

Below are rapidly actionable ways to start enforcing existing policies:

  1. Adopt Basic Monitoring or Reporting

  2. Automate Alerts for Major Breaches

  3. Introduce Basic Consequence Management

    • If a policy is violated, require the team to fill out an exception form or gain approval from a manager.
    • This ensures staff think twice before ignoring policy.

  4. Incrementally Expand Enforcement

    • Start with “auditing mode,” then gradually move to “deny mode.” For example:
      • In AWS, use Service Control Policies or AWS Config rules in “detect-only” mode first, then enforce.
      • In Azure, run Azure Policy in “audit” effect, then shift to “deny” once comfortable.
      • GCP or OCI similarly allow rules to initially only log and then eventually block non-compliant actions.

By automating policy checks, alerting on critical breaches, and phasing in enforcement, you build momentum toward consistent compliance without overwhelming teams.

Process-Driven Application: Policies are applied primarily through organisational processes without significant technical support.

How to determine if this good enough

In this scenario, your organisation integrates policies into formal workflows (e.g., ticketing, approval boards, or documented SOPs), but relies on manual oversight rather than automated technical controls. It could be “good enough” if:

  1. Stable, Well-Understood Environments

    • Your systems don’t change frequently, so manual approvals or reviews remain feasible.
    • The pace of service updates is relatively slow.

  2. Well-Trained Staff

    • Teams consistently follow these processes, knowing policy steps are mandatory.
    • Leadership or compliance officers occasionally check random samples for compliance.

  3. Low Complexity

    • A small number of applications or resources means manual reviews remain practical, and the risk of missing a violation is relatively low.

However, process-driven approaches can become slow and error-prone with scale or complexity. If you spin up ephemeral environments or adopt rapid CI/CD, purely manual processes might lag behind or fail to catch mistakes.

How to do better

Below are rapidly actionable ways to enhance process-driven application:

  1. Introduce Lightweight Technical Automation

  2. Use a Single Source of Truth

    • Store policy documentation and forms in a single location (e.g., SharePoint, Confluence, or an internal Git repo).
    • This avoids confusion about which version of the process to follow.

  3. Add a “Policy Gate” to Ticketing Systems

    • For example, in ServiceNow or Jira:
      • A ticket for provisioning a new VM or network must pass a “policy gate” status, requiring sign-off from a compliance or security person referencing your standard steps.

  4. Measure Process Efficiency

    • Track how long it takes to apply each policy step. Identify bottlenecks or missed checks.
    • This helps you see where minimal automation or additional staff training could cut manual overhead.

  5. Conduct Periodic Spot Audits

    • Check a random subset of completed tickets or new resources to ensure every policy step was genuinely followed, not just ticked off.
    • Publicise the outcomes so staff remain vigilant.

By introducing minor automation, centralising policy references, adding a policy gate in ticketing, and auditing process compliance, you blend the reliability of your current manual approach with the efficiency gains of technical enablers.

Process-Driven with Limited Technical Control: Policies are comprehensively applied through processes, supported by limited technical control mechanisms.

How to determine if this good enough

At this stage, your organisation uses well-defined processes to ensure policy compliance, supplemented by some technical controls (e.g., partial automation or read-only checks). You might consider it “good enough” if:

  1. Consistent, Repeatable Processes

    • Your staff frequently comply with policy steps.
    • Automated checks (like scanning for open ports or misconfigurations) reduce human errors.

  2. Reduced Overheads

    • Some tasks are automated, but you still rely on manual gating in certain high-risk or high-sensitivity areas.
    • This balance feels manageable for your scale and risk profile.

  3. Positive Audit Outcomes

    • Internal or external audits indicate that your policy application is robust, with only minor improvements needed.

However, if you want to handle larger workloads or adopt faster continuous delivery, you might need more comprehensive technical enforcement that eliminates many manual steps and further reduces the chance of oversight.

How to do better

Below are rapidly actionable ways to reinforce or extend your existing setup:

  1. Expand Technical Enforcement

  2. Integrate Observability and Alerting

  3. Adopt “Immutability” or “Infrastructure as Code”

  4. Push for More Cross-Team Training

    • Ensure DevOps, security, and compliance teams understand how to interpret automated policy checks.
    • This fosters a shared sense of ownership and makes the half-automated approach more effective.

  5. Set Up a Policy Remediation or “Self-Healing” Mechanism

    • Where feasible, let your system automatically fix minor compliance drifts:
      • e.g., If a bucket is created public by mistake, the system reverts it to private and notifies the user.

By strengthening technical guardrails, improving alerting, and embedding your policies deeper into IaC, you evolve your limited technical controls into a more comprehensive and proactive enforcement model.

Fully Integrated Application and Enforcement: Policies are applied and enforced comprehensively through well-established processes, with robust technical controls executed at all stages.

How to determine if this good enough

At this final stage, policy application is deeply woven into both organisational processes and automated technical controls:

  1. End-to-End Enforcement

    • Every step of resource creation, modification, or retirement is governed by your policy—there’s no easy workaround or manual override without documented approval.

  2. High Automation, High Reliability

    • The majority of policy compliance checks and remediation are automated. Staff rarely need to intervene except for unusual exceptions.

  3. Predictable Governance

    • Audits or compliance reviews are smooth. Minimal policy violations occur, and if they do, they’re swiftly detected and addressed.

  4. Alignment with Public Sector Standards

    • You likely meet or exceed typical security or compliance frameworks, easily demonstrating robust controls to oversight bodies.

Even at this apex, continuous improvement remains relevant. Evolving technology or new departmental mandates might require ongoing updates to maintain best-in-class enforcement.

How to do better

Below are rapidly actionable refinements, even at the highest maturity:

  1. Adopt Policy-as-Code with Automated Testing

  2. Enable Dynamic, Real-Time Adjustments

    • Some advanced organisations adopt “adaptive policies” that can respond automatically to shifting risk contexts:
      • e.g., Requiring step-up authentication or extra scanning if abnormal usage patterns appear.

  3. Analytics and Reporting on Policy Efficacy

    • Track metrics like “time to resolve policy violations,” “number of exceptions requested per quarter,” or “percentage of resources in compliance.”
    • Present these metrics to leadership for data-driven improvements.

  4. Cross-department Collaboration

    • If you share data or resources with other public sector agencies, coordinate policy definitions or enforcement bridging solutions.
    • This ensures consistent governance and security across multi-department projects.

  5. Regularly Test Failover or Incident Response

    • Conduct simulation exercises to confirm that policy enforcement remains intact during partial outages or security incidents.
    • Evaluate whether the automated controls effectively protect resources and whether manual overrides are restricted or well-logged.

By implementing policy-as-code with automated testing, adopting dynamic enforcement, collecting analytics on compliance, and performing cross-department or incident drills, you ensure your integrated model remains agile and robust—setting a high benchmark for public sector governance.

Keep doing what you’re doing, and consider writing internal blog posts or external case studies about your policy enforcement journey. Submit pull requests to this guidance or related public sector best-practice repositories so others can learn from your advanced application and enforcement strategies.

How is version control and branch strategy implemented in your organisation?

Limited Version Control Usage: Version control is used minimally, indicating a lack of robust processes for managing code changes and history.

How to determine if this good enough

Your organisation may store code in a basic repository (sometimes not even using Git) with minimal branching or tagging. This might be “good enough” if:

  1. Small/Short-Term Projects

    • Projects with a single developer or short lifespans, where overhead from advanced version control might not be justified.

  2. Low Collaboration

    • Code changes are infrequent, or there’s no simultaneous development that requires merges or conflict resolution.

  3. Non-Critical Systems

    • Failure or regression from insufficient version control poses a manageable risk with minimal user impact.

Still, even small projects benefit from modern version control practices (e.g., Git-based workflows). NCSC’s advice on code security and NIST SP 800-53 CM controls recommend robust version control to ensure traceability, reduce errors, and support better compliance and security.

How do I do better?

How do I do better?

Below are rapidly actionable next steps:

  1. Pick a Git-based Platform

  2. Require Commits for Every Change

  3. Document Basic Workflow

  4. Tag Notable Versions

    • If something is “ready for release,” apply a Git tag or version (e.g., v1.0).
    • Minimises guesswork about which commit correlates to a live environment.

  5. Plan for Future Branching Strategy

    • Over 3–6 months, adopt a recognised model (e.g., GitHub Flow or trunk-based) to handle multiple contributors or features.

By using a modern Git-based platform, ensuring all changes result in commits, documenting a minimal workflow, tagging key releases, and scheduling a shift to a recognised branching strategy, you quickly move from minimal version control to a more robust approach that supports collaboration and security needs.

Custom, Unconventional Branch Strategy: An invented branch strategy is in use, not aligning with standard methodologies and potentially leading to confusion or inefficiencies.

How to determine if this good enough

Your team might have created a unique branching model. This can be “good enough” if:

  1. Small Team Agreement

    • Everyone understands the custom approach, and the risk of confusion is low.

  2. Limited Cross-Team Collaboration

    • You rarely face external contributors or multi-department merges, so you haven’t encountered significant friction.

  3. Works for Now

    • The custom approach meets current needs and hasn’t caused major merge issues or frequent conflicts yet.

That said, widely recognised branch strategies (GitFlow, GitHub Flow, trunk-based development) typically reduce confusion and are better documented. NCSC’s developer best practices and NIST SP 800-160 secure engineering frameworks encourage standard solutions for consistent security and DevOps.

How do I do better?

How do I do better?

Below are rapidly actionable methods to move from a custom approach to a standard one:

  1. Map Existing Branching to a Known Strategy

  2. Document a Cross-Reference

    • If you choose GitFlow, rename your custom “hotfix” or “dev” branches to align with standard naming, making it easier for new joiners.

  3. Simplify Where Possible

    • Some custom strategies overcomplicate merges. Consolidate or reduce the number of long-lived branches to avoid confusion.

  4. Provide a Quick “Cheatsheet”

  5. Pilot a Standard Flow on a New Project

    • In parallel, adopt a recognised model (e.g., GitHub Flow) on a small project to gain team familiarity before rolling it out more widely.

By comparing your custom model to standard flows, documenting a cross-reference, simplifying branch use, providing a quick reference, and trialing a standard approach on a new project, you reduce complexity and align with recognised best practices.

Adapted Recognised Branch Strategy: The organisation adapts a recognised branch strategy (like GitFlow or GitHubFlow), tailoring it to specific needs while maintaining some standard practices.

How to determine if this good enough

You follow a known model (GitFlow, trunk-based, or GitHub Flow) but adapt it for local constraints. This is often “good enough” if:

  1. Shared Terminology

    • Most developers grasp main concepts (e.g., “feature branches,” “release branches”), reducing confusion.

  2. Appropriate for Complexity

    • If your application requires multiple parallel releases or QA stages, GitFlow might be suitable, or if you have frequent small merges, trunk-based might excel.

  3. Relatively Low Merge Conflicts

    • The adapted approach helps you handle concurrent changes with minimal chaos.

If you still encounter friction (e.g., complex release branches rarely used, too many merges), you could refine or consider a simpler approach. NCSC’s DevSecOps guidance and NIST SP 800-53 CM controls underscore the importance of an approach that’s not overly burdensome yet robust enough for security and compliance.

How do I do better?

How do I do better?

Below are rapidly actionable improvements:

  1. Document the Adaptations

    • Clarify how your version of GitFlow or trunk-based differs from the original.
    • Minimises onboarding confusion.

  2. Regularly Revisit Branch Usage

  3. Incorporate CI/CD Automation

  4. Train New Team Members

  5. Simplify for Next Project

    • If you find the strategy too complex for frequent releases, consider trunk-based or GitHub Flow on your next new service or microservice.

By documenting your adaptations clearly, removing unused branches, adding CI/CD hooks for every branch commit, onboarding new developers, and evaluating simpler flows for future projects, you ensure your branch strategy remains practical and efficient.

Textbook Implementation of a recognised branch strategy: The organisation adheres strictly to a model such as GitFlow, a recognised branch strategy suitable for managing complex development processes.

How to determine if this good enough

You employ a formal version of GitFlow (or a similarly structured approach) with separate “develop,” “release,” “hotfix,” and “feature” branches. It can be “good enough” if:

  1. Complex or Multiple Releases

    • You manage multiple versions or release cycles in parallel, which GitFlow accommodates well.

  2. Stable Processes

    • Teams understand and follow GitFlow precisely, with few merges or rebase conflicts.

  3. Clear Roles

If you see minor friction in fast iteration or dev complaining about overhead, you might consider a simpler trunk-based approach. GOV.UK Service Manual on continuous delivery suggests simpler flows often suffice for agile teams.

How do I do better?

How do I do better?

Below are rapidly actionable ways to optimise a textbook GitFlow-like approach:

  1. Apply Automated Merges/Sync

  2. Monitor Branch Sprawl

    • Limit the number of concurrent “release” branches.
    • If dev sees multiple releases with cross-pollination, consider if a simpler model might be more agile.

  3. Include Security Checks per Branch

  4. Document Rarely Used Branches

    • If your GitFlow includes “hotfix” or “maintenance” branches rarely used, confirm usage patterns or retire them for simplicity.

  5. Evaluate Branch Strategy Periodically

    • Every 6–12 months, revisit whether GitFlow remains necessary or trunk-based dev might serve better for speed.

By automating merges, controlling branch sprawl, embedding security checks into every branch, documenting rarely used branches, and regularly re-evaluating your overall branching structure, you keep your textbook GitFlow or similar approach practical and effective.

Textbook Implementation of a streamlined branch strategy: The organisation follows a streamlined branch strategy ideal for continuous delivery and simplified collaboration such as GitHubFlow precisely.

How to determine if this good enough

You adopt a minimal branching approach—like trunk-based development or GitHub Flow—emphasizing rapid merges and continuous integration. It’s likely “good enough” if:

  1. Frequent Release Cadence

    • You can deploy changes daily or multiple times per day without merge conflicts piling up.

  2. Highly Agile Culture

    • The team is comfortable merging into main or trunk quickly, with automated tests ensuring no regressions.

  3. Confidence in Automated Tests

    • A robust CI pipeline instills trust that quick merges rarely break production.

Still, for some large or multi-release scenarios (like long-term LTS versions), a more complex branching model might help. NCSC agile DevSecOps guidance and NIST SP 800-160 for secure engineering at scale provide additional references on maintaining code quality with frequent releases.

How do I do better?

How do I do better?

Below are rapidly actionable ways to refine a minimal branch strategy:

  1. Expand Test Coverage

  2. Establish Feature Flags

  3. Enforce Peer Review

  4. Set Real-Time Release Observability

  5. Encourage Short-Lived Branches

    • Keep branches open for days or less, not weeks, ensuring minimal drift from main and fewer merge conflicts.

By strengthening test coverage, leveraging feature flags, requiring peer reviews, observing real-time release metrics, and promoting short-lived branches, you optimise a streamlined approach that fosters continuous delivery and rapid iteration aligned with modern DevSecOps standards.

Keep doing what you’re doing, and consider sharing your version control and branching strategy successes through blog posts or contributing them as best practices. This helps other UK public sector organisations adopt effective workflows aligned with NCSC, NIST, and GOV.UK guidance for secure, efficient software development.

What is your primary method for provisioning cloud services?

Manual or Imperative Provisioning: Cloud services are primarily provisioned manually through consoles, portals, CLI, or other tools, without significant automation.

How to determine if this good enough

If your organisation primarily provisions cloud services using manual methods—such as web consoles, command-line interfaces, or custom ad hoc scripts—this might be considered “good enough” if:

  1. Very Small or Low-Risk Environments

    • You run minimal workloads, handle no highly sensitive data, and rarely update or modify your cloud infrastructure.

  2. Limited Scalability Needs

    • You do not expect frequent environment changes or expansions, so the overhead of learning automation might seem unnecessary.

  3. No Immediate Compliance Pressures

    • You might not be heavily audited or required to meet advanced DevOps or infrastructure-as-code (IaC) practices just yet.

However, as soon as your environment grows, new compliance demands appear, or you onboard more users, manual provisioning can lead to inconsistencies and difficulty tracking changes—particularly in the UK public sector, where robust governance is often required.

How to do better

Below are rapidly actionable steps to move beyond purely manual provisioning:

  1. Start Capturing Configurations in Scripts

  2. Implement Basic Naming and Tagging Conventions

    • Create a short doc listing agreed naming prefixes/suffixes and mandatory tags:
      • e.g., DepartmentName, Environment (Dev/Test/Prod), Owner tags.
    • This fosters consistency and prepares for more advanced automation.

  3. Add a Simple Approval Step

    • If you’re used to provisioning without oversight, set up a minimal “approval check.”
    • For instance, use a shared Slack or Teams channel where you post new resource requests, and a manager or security person acknowledges before provisioning.

  4. Consider a Pilot with Infrastructure as Code (IaC)

  5. Document Provisioning Steps

    • Keep a simple runbook or wiki page. Summarise each manual provisioning step so you can easily shift these instructions into scripts or templates later.

By scripting basic tasks, implementing a simple naming/tagging policy, adding minimal approvals, and piloting an IaC solution, you start transitioning from ad hoc provisioning to more consistent automation practices.

Limited Scripting with No Standards: Provisioning involves some scripting, but there are no formal standards or consistency across project teams.

How to determine if this good enough

In this scenario, your organisation uses partial automation or scripting, but each team might have its own approach, with no centralised or standardised method. You might consider it “good enough” if:

  1. Small to Medium Environment

    • Teams are somewhat comfortable with their own scripting techniques.
    • No pressing requirement to unify them under a single approach.

  2. Mixed Expertise

    • Some staff are proficient with scripting (Python, Bash, PowerShell), but others prefer manual console methods.
    • You haven’t faced major issues from inconsistent naming or versioning.

  3. Infrequent Collaboration

    • Your departments rarely need to share cloud resources or code, so differences in scripting style haven’t caused big problems.

However, as soon as cross-team projects arise or you face compliance demands for consistent infrastructure definitions, this fragmentation can lead to duplication of effort, confusion, and errors.

How to do better

Below are rapidly actionable ways to standardise your provisioning scripts:

  1. Adopt a Common Repository for Scripts

    • Create an internal Git repo (e.g., on GitHub, GitLab, or a cloud-hosted repo) for all provisioning scripts:
    • Encourage teams to share and reuse scripts, aligning naming conventions and code structure.

  2. Define Minimal Scripting Standards

    • E.g., standard file naming, function naming, environment variable usage, or logging style.
    • Keep it simple but ensure each team references the same baseline.

  3. Use Infrastructure as Code Tools

  4. Create a Shared Module or Template Library

    • If multiple teams need similar infrastructure (e.g., a standard VPC, a typical storage bucket), store that logic in a common template or module:
      • e.g., Terraform modules in a shared Git repo or a private registry.
    • This ensures consistent best practices are used across all projects.

  5. Encourage Collaboration and Peer Reviews

    • Have team members review each other’s scripts or templates in a code review process, catching mistakes and unifying approaches along the way.

By consolidating scripts in a shared repository, defining lightweight standards, introducing IaC tools, and fostering peer reviews, you gradually unify your provisioning process and reduce fragmentation.

Partial Declarative Automation: Declarative automation is used for provisioning some cloud services across their lifecycle, but this practice is not uniform across all teams.

How to determine if this good enough

Declarative automation (often in the form of Infrastructure as Code) is partially adopted, but not every team or environment follows it consistently. This might be “good enough” if:

  1. Sisable Gains in Some Areas

    • Some major projects are stable, reproducible, and versioned via IaC, reducing manual errors.
    • Other smaller or legacy teams might still rely on older methods.

  2. Limited Conflict Among Teams

    • While some teams use IaC and others don’t, there isn’t a high need to integrate or share resources.
    • Each team can operate fairly independently without causing confusion.

  3. Compliance and Control

    • Where the stakes are high (e.g., production or sensitive data), you likely already enforce declarative approaches.
    • Lower-priority or test environments remain behind, but that may be acceptable for now.

If partial declarative automation meets your current needs, you may decide it’s sufficient. However, you might miss out on consistent governance, easier cross-team collaboration, and uniform operational efficiency.

How to do better

Below are rapidly actionable ways to expand your declarative automation:

  1. Set Organisation-Wide IaC Defaults

    • Decide on a primary IaC tool (Terraform, CloudFormation, Bicep, Deployment Manager, or others) and specify guidelines:
      • e.g., “All new infrastructure that goes to production must use Terraform for provisioning, with code in X repo.”

  2. Create a Reference Architecture or Template

  3. Extend IaC Usage to Lower Environments

    • Even for dev/test, use declarative templates so staff get comfortable and maintain consistency:
      • This ensures the same patterns scale up to production effortlessly.

  4. Implement Automated Checks

  5. Offer Incentives for Adoption

    • e.g., Team metrics or internal recognition if all new deployments use IaC.
    • Showcase success stories: “Team A reduced production incidents by 30% after adopting IaC.”

By standardising your IaC approach, providing shared templates, enforcing usage even in lower environments, and automating checks, you accelerate your journey toward uniform, declarative provisioning across teams.

Widespread Use of Declarative Automation: Most project teams employ declarative automation for cloud service provisioning, indicating a higher level of maturity in automation practices.

How to determine if this good enough

In this phase, a large majority of your teams rely on IaC or declarative templates to provision and manage cloud services, yielding consistency and reliability. You might consider it “good enough” if:

  1. High Reusability and Efficiency

    • Teams share modules, templates, or code with minimal duplication.
    • Common services (e.g., VPC, subnets, security groups) are easily spun up.

  2. Improved Compliance and Auditing

    • Audits show that configurations match version-controlled definitions—reducing manual drift.
    • Staff can quickly roll back or replicate environments for test or disaster recovery.

  3. Reduced Operational Overhead

    • Fewer manual changes mean fewer untracked variations.
    • Teams typically see improved speed for launching new environments.

If your use of declarative automation is broad but not yet mandated for every environment, you might still face occasional manual exceptions or unapproved changes. This can lead to minor inconsistencies.

How to do better

Below are rapidly actionable ways to continue refining:

  1. Integrate with CI/CD Pipelines

  2. Establish a Platform Engineering or DevOps Guild

    • A cross-team group can maintain shared IaC libraries, track upgrades, and collaborate on improvements.
    • This fosters ongoing enhancements and helps new teams onboard quickly.

  3. Strengthen Security and Compliance Automation

    • Embed more advanced checks into your IaC pipeline:
      • e.g., verifying that certain resources cannot be exposed to the public internet, forcing encryption at rest, etc.

  4. Expand to Multi-Cloud or Hybrid

    • If relevant, unify your IaC approach for resources across multiple clouds or on-prem environments:
      • Tools like Terraform can handle multi-cloud provisioning under one codebase.

  5. Continue Upskilling Staff

    • Offer advanced IaC training, sessions on best practices, or pair programming to help teams adopt more sophisticated patterns (modules, dynamic references, etc.).

By using formal CI/CD for all deployments, fostering a DevOps guild, strengthening compliance checks, and supporting multi-cloud approaches, you refine widespread IaC usage into a highly orchestrated, reliable practice across the organisation.

Mandatory Declarative Automation via CI/CD: Declarative automation is mandated for provisioning all production services, and it is exclusively executed through Continuous Integration/Continuous Deployment (CI/CD) pipelines.

How to determine if this good enough

This final stage means your organisation has fully embraced IaC—any production environment changes occur only through a pipeline and must be defined declaratively. It’s likely “good enough” if:

  1. Extremely Consistent Environments

    • No drift, as manual changes in production are disallowed or quickly overwritten by pipeline definitions.

  2. Robust Governance

    • Audits and compliance are straightforward—everything is in version control and accompanied by pipeline logs.

  3. Seamless Reproducibility

    • Dev, staging, and production can match precisely, barring data differences.
    • Rapid rollback is possible by reverting to a previous commit.

  4. High Organisational Discipline

    • All stakeholders adhere to the policy that “no code, no deploy”—any infrastructure change must be made in IaC first.

You already operate at a high maturity level. Still, continuous improvement might revolve around advanced testing, policy-as-code integration, and cross-organisational collaboration.

How to do better

Below are rapidly actionable ways to push the boundaries, even at the highest maturity:

  1. Implement Policy-as-Code

  2. Adopt Advanced Testing and Security Checks

    • Extend your pipeline to run static code analysis (SAST), dynamic checks (DAST), and security scanning for container images or VM base images.
    • Provide a thorough “shift-left” approach, catching issues pre-production.

  3. Introduce Automated Change Approvals

    • If you want a “human in the loop” for major changes, use pipeline gating:
      • e.g., a Slack or Teams approval step before applying infrastructure changes in production.
    • This merges automation with the final manual sign-off for critical changes.

  4. Evolve Toward Self-Service Platforms

  5. Expand to True “GitOps” for Ongoing Management

    • Continuously synchronise changes from Git to your runtime environment:
      • e.g., using FluxCD or ArgoCD for containerised workloads, or hooking a Terraform operator into a Git repo.

By integrating policy-as-code, advanced security checks, optional gating approvals, self-service catalogs, and GitOps strategies, you refine your mandatory declarative automation approach into a truly world-class, highly efficient model of modern cloud provisioning for the UK public sector.

Keep doing what you’re doing, and consider sharing internal or external blog posts about your provisioning automation journey. Submit pull requests to this guidance or similar public sector best-practice repositories to help others learn from your experiences and successes.

Operations

How comprehensive is the use of CI/CD tooling in your organisation?

No CI/CD Tooling: Traditional build, test, and deploy practices are in use, with no implementation of CI/CD tooling.

How to determine if this good enough

Your organisation may still rely on manual or semi-manual processes for building, testing, and deploying software. You might consider this “good enough” if:

  1. Small or Non-Critical Projects

    • You run a limited set of applications with low release frequency, so manual processes remain manageable.

  2. Low Risk Tolerance

    • The team is not yet comfortable adopting new automation tools or processes, and there is no immediate driver to modernise.

  3. Minimal Compliance Pressures

    • Formal requirements (e.g., from internal governance, GDS Service Standards, or security audits) haven’t mandated an automated pipeline or detailed audit trail for deployments.

However, as your projects grow, manual building and deploying typically becomes time-consuming and prone to human error. This can lead to inconsistency, difficulty replicating production environments, and a slower pace of iteration.

How to do better

Below are rapidly actionable steps to adopt a basic CI/CD foundation:

  1. Begin with Simple Scripting

  2. Implement Basic Automated Testing

    • Start by automating unit tests:
      • Each commit triggers a script that runs tests in a shared environment, providing at least a “pass/fail” outcome.

  3. Use a Shared Version Control Repository

    • If you’re not already using one, adopt Git (e.g., GitHub, GitLab, or an internal service) to store your source code so that you can begin integrating basic CI steps.

  4. Document the Process

    • Create a short runbook or wiki entry explaining how code is built, tested, and deployed.
    • This helps new team members adopt the new process.

  5. Set a Goal to Remove Manual Steps Gradually

    • Identify the most error-prone or time-consuming manual tasks. Automate them first to gain quick wins.

By introducing simple build/test scripting, hosting code in version control, and documenting your process, you establish the baseline for a more formal CI/CD pipeline in the future.

Limited CI/CD Tooling on Some Projects: CI/CD tooling is used by some projects, but there are no formal standards or widespread adoption across the organisation.

How to determine if this good enough

When some teams have adopted CI/CD pipelines for build and deploy tasks, but others remain manual or partially automated, you might find this “good enough” if:

  1. Partial Automation Success

    • Projects that do have CI/CD show faster releases and fewer errors, indicating the benefits of automation.

  2. Mixed Team Maturity

    • Some teams have the skills or leadership support to implement pipelines, while others do not, and there’s no pressing need to unify.

  3. No Major Interdependence

    • Projects that use CI/CD operate somewhat independently, not forcing standardisation across the entire organisation.

While this can work for a period, inconsistent CI/CD adoption often leads to uneven release quality, slower integration across departments, and missed opportunities for best-practice sharing.

How to do better

Below are rapidly actionable ways to broaden CI/CD usage:

  1. Establish a Centralised CI/CD Reference

    • Create an internal wiki or repository showcasing how leading teams set up their pipelines:
    • Encourage other teams to replicate successful patterns.

  2. Provide or Recommend CI/CD Tools

  3. Host Skill-Sharing Sessions

    • Have teams currently using CI/CD present their approaches in short lunch-and-learn sessions.
    • Record these sessions so new staff or less mature teams can learn at their own pace.

  4. Create Minimal Pipeline Templates

    • Provide a starter template for each major language or platform (e.g., Node.js, Java, .NET).
    • Ensure these templates include basic build, test, and package steps out of the box.

  5. Reward Cross-Team Collaboration

    • If a more advanced project helps a struggling team set up their pipeline, recognise both parties’ efforts.
    • This fosters a culture of internal assistance rather than siloed approaches.

By sharing knowledge, offering recommended tools, and providing example templates, you organically expand CI/CD adoption and empower teams to adopt consistent approaches.

Varied CI/CD Tooling Across Teams: Many project teams use CI/CD tooling, though the choice of tools and practices is based on individual team preferences.

How to determine if this good enough

This stage sees widespread CI/CD usage across the organisation, but with each team choosing different pipelines, scripts, or orchestrators. You might consider it “good enough” if:

  1. Strong Automation Culture

    • Almost every project has some form of automated build/test/deploy.
    • Productivity and reliability are generally high.

  2. High Team Autonomy

    • Teams appreciate the freedom to select the best tools for their stack.
    • Little friction arises from differences in pipeline tech, as cross-team collaboration is limited or well-managed.

  3. No Major Standardisation Requirement

    • Your department or top-level governance body hasn’t mandated a single CI/CD framework.
    • Audits or compliance checks are typically satisfied by each team’s pipeline logs and versioning practices.

Though beneficial for agility, this approach can hinder knowledge sharing and pose onboarding challenges if staff move between teams. Maintaining multiple toolchains might also increase overhead.

How to do better

Below are rapidly actionable ways to refine or unify CI/CD tool usage:

  1. Define Core Principles or Best Practices

    • Even if each team chooses different tools, align on key principles:
      • Every pipeline must run unit tests, produce build artifacts, and store logs.
      • Every pipeline must integrate with code reviews and version control.
    • This ensures consistency of outcomes, if not standard tooling.

  2. Document Cross-Tool Patterns

    • Create a short doc or wiki explaining how to handle:
      • Secrets management, environment variables, artifact storage, and standard branch strategies.
    • This helps teams use the same approach to security and governance, even if they use different CI/CD apps.

  3. Encourage Modular Pipeline Code

    • Teams can share modular scripts or config chunks for tasks like static analysis, security checks, or environment provisioning:
      • e.g., Docker build modules, Terraform integration steps, or test coverage logic.

  4. Highlight or Mentor

    • If certain pipelines are especially successful, highlight them as “recommended” or offer mentorship so other teams can replicate their approach.
    • Over time, the organisation may naturally converge on a handful of widely accepted tools.

  5. Consider a Central CI/CD Service for Key Use Cases

By defining core CI/CD principles, documenting shared patterns, and selectively offering a central service or recommended tool, you maintain team autonomy while reaping benefits of consistent practices.

Widespread, Team-Preferred CI/CD Tooling: Most project teams employ CI/CD tooling, largely based on team preferences, with traditional practices being very limited.

How to determine if this good enough

In this stage, nearly all projects have automated pipelines, but there may still be variety in the tooling. Traditional or manual deploys exist only in niche situations. You might consider this “good enough” if:

  1. Robust Automation Coverage

    • A large percentage of code changes are tested and deployed automatically, minimising manual overhead.
    • Releases are quicker and more reliable.

  2. Limited Governance or Standardisation Issues

    • Management is not demanding a single solution, and teams are content with the performance and reliability of their pipelines.

  3. Minor Complexity

    • While multiple CI/CD solutions exist, knowledge sharing is still manageable, and staff do not struggle excessively when rotating between teams.

If your approach still creates confusion for new or cross-functional staff, you might gain from more standardisation. Also, advanced compliance or security scenarios may benefit from a more centralised approach.

How to do better

Below are rapidly actionable ways to refine widespread team-driven CI/CD:

  1. Introduce a DevOps Guild or CoE (Center of Excellence)

    • Regularly meet with representatives from each team, discussing pipeline improvements, new features, or security issues.
    • Gather best practices in a single location.

  2. Further Integrate Security (DevSecOps)

  3. Standardise Basic Access & Observability

    • Regardless of the pipeline tool, ensure:
      • A consistent approach to storing build logs and artifacts, tagging builds with version numbers, and applying RBAC for pipeline access.
    • This unifies the data your compliance officers or governance teams rely on.

  4. Automate Approvals for Critical Environments

    • If production deployments require sign-off, implement a pipeline-based approval process:
      • e.g., Slack or Teams-based approval checks, or an integrated manual approval step in the pipeline (Azure DevOps, GitHub Actions, GCP Cloud Build triggers, or AWS CodePipeline).

  5. Measure Pipeline Performance and Reliability

    • Gather metrics like average build time, deployment success rate, or lead time for changes.
    • Use these insights to target pipeline improvements or unify slow or error-prone steps.

By fostering a DevOps guild, infusing security checks, and unifying logging/artifact storage, you balance team autonomy with enough cross-cutting standards to maximise reliability and compliance.

Standardised and Consistent CI/CD Practices: A standardised CI/CD pipeline is consistently used across project teams organisation-wide, indicating a high level of maturity in deployment practices.

How to determine if this good enough

At this stage, your organisation has converged on a common CI/CD approach. You might consider it “good enough” if:

  1. Uniform Tools and Processes

    • All teams share a similar pipeline framework, leading to consistent build, test, security, and deployment steps.
    • Onboarding is smoother—new staff learn one method rather than many.

  2. High Governance and Compliance Alignment

    • Auditing deployments is straightforward, as logs, artifacts, and approvals follow the same structure.
    • Security or cost-optimisation checks are consistently applied across all services.

  3. Continuous Improvement

    • Each pipeline improvement (e.g., adding new test coverage or scanning) benefits the entire organisation.
    • Teams collaborate on pipeline updates rather than reinventing the wheel.

While standardisation solves many issues, organisations must remain vigilant about tool stagnation. If the environment evolves (e.g., new microservices, containers, or serverless solutions), you should continuously update your pipeline approach.

How to do better

Below are rapidly actionable ways to refine your standardised CI/CD practices:

  1. Adopt Pipeline-as-Code for All

  2. Implement Advanced Deployment Strategies

    • For example, canary or blue/green deployments:
      • This reduces downtime and risk during releases, making your pipelines more robust.

  3. Integrate Policy-as-Code

    • Ensure pipeline runs automatically verify compliance with organisational policies:
      • e.g., scanning IaC templates or container images for security or cost violations, referencing official standards.

  4. Expand Observability

    • Offer real-time dashboards for build success rates, deployment times, and test coverage.
    • Publish these metrics in a central location so leadership and cross-functional teams see progress.

  5. Encourage “Chaos Days” or Hackathons

    • Let teams experiment with pipeline improvements, new integration patterns, or novel reliability tests.
    • This fosters ongoing innovation and ensures your standardised approach does not become static.

By version-controlling pipeline definitions, embracing advanced deployment patterns, integrating policy checks, and driving continuous improvement initiatives, you keep your standardised CI/CD framework at the cutting edge—well-aligned with UK public sector priorities of robust compliance, reliability, and efficiency.

Keep doing what you’re doing, and consider writing up your CI/CD journey in internal blog posts or knowledge bases. Submit pull requests to this guidance or related public sector best-practice repositories so others can learn from your experiences as well.

How does your organisation ensure that applications are built and deployed in a timely manner?

No Routine Measurements, Slow Processes: There are no routine measurements for build and deployment times. Builds and deployments often take days to plan and hours to execute, with little monitoring for SLA compliance.

How to determine if this good enough

At this level, your organisation may treat builds and deployments as irregular events with minimal oversight. You might consider it “good enough” if:

  1. Very Low Release Frequency

    • You only release occasionally (e.g., once every few months), so tracking speed or efficiency seems less critical.
    • Slow deployment cycles are acceptable due to stable requirements or minimal user impact.

  2. Limited Pressure from Stakeholders

    • Internal or external stakeholders do not demand quick rollouts or frequent features, so extended lead times go unchallenged.

  3. No Critical Deadlines

    • Lacking strict compliance or operational SLA obligations, you might not prioritise faster release cadences.

However, as soon as your environment grows, user demands increase, or compliance regulations require more frequent updates (e.g., security patches), slow processes can create risk and bottlenecks.

How to do better

Below are rapidly actionable steps to introduce basic measurements and reduce build/deployment durations:

  1. Implement a Simple Tracking Mechanism

    • Start by documenting each deployment’s start and end times in a spreadsheet or ticket system:
      • Track which environment was deployed, total time taken, any blockers encountered.
    • Over a few weeks, you’ll get a baseline for improvement.

  2. Automate Basic Steps

  3. Adopt a Central Version Control System

    • If you aren’t already, store source code and deployment artifacts in Git (e.g., GitHub, GitLab, Azure Repos, etc.):
    • This lays the groundwork for more advanced automation later.

  4. Introduce Basic SLAs for Deployment Windows

    • e.g., “We aim to complete production deployments within 1 working day once approved.”
    • This ensures staff start to see time-to-deploy as a priority.

  5. Identify Key Bottlenecks

    • Are approvals causing delays? Are you waiting for a single SME to do manual steps?
    • Focus on automating or streamlining the top pain point first.

By tracking deployments in a simple manner, automating the most time-consuming tasks, and setting minimal SLAs, you begin reducing deployment time and gain insight into where further improvements can be made.

Basic Tracking with Some Delays: Some basic tracking of build and deployment times is in place, but processes are still relatively slow, often resulting in delays.

How to determine if this good enough

At this level, you record how long builds and deployments take, but you still experience extended lead times. You might consider it “good enough” if:

  1. Moderately Frequent Releases

    • You release a new version monthly or quarterly, and while not fast, it meets your current expectations.

  2. Limited Pressure from Users

    • Stakeholders occasionally push for quicker releases, but the demand remains manageable.
    • You deliver essential updates without major user complaints.

  3. Some Awareness of Bottlenecks

    • You know where delays occur (e.g., environment setup, manual test cycles), but you haven’t tackled them systematically.

If your team can tolerate these delays and no critical issues arise, you might remain here temporarily. However, you risk frustrating users or missing security patches if you can’t accelerate when needed.

How to do better

Below are rapidly actionable ways to reduce delays and evolve your tracking:

  1. Automate Testing

  2. Streamline Approvals

    • If manager sign-off is causing long waits, propose a structured yet efficient approval flow:
      • For example, define a Slack or Teams channel where changes can be quickly acknowledged.
      • Use a ticket system or pipeline-based manual approval steps that require minimal overhead.

  3. Implement Parallel or Incremental Deployments

    • Instead of a big-bang approach, deploy smaller changes more frequently:
      • If teams see fewer changes in each release, testing and validation can be quicker.

  4. Enforce Clear Deployment Windows

    • e.g., “Production deploys occur every Tuesday and Thursday at 2 PM,” with a cut-off for code submissions.
    • This planning reduces ad hoc deployments that cause confusion.

  5. Set Target Timelines

    • e.g., “Builds should not exceed 30 minutes from commit to artifact,” or “Deployments to test environments should complete within an hour of code merges.”
    • Start small, measure progress, and refine goals.

By adding automated testing, simplifying approvals, and promoting incremental deployments, you shorten delays and create a more responsive release pipeline.

Moderate Efficiency with Occasional Monitoring: The organisation has moderately efficient build and deployment processes, with occasional monitoring and efforts to adhere to timelines.

How to determine if this good enough

If you see mostly consistent build and deploy times—often measured in hours or under a day—and have some checks to ensure timely releases, you might consider it “good enough” if:

  1. Regular Release Cadence

    • You release weekly or bi-weekly, and while it’s not fully streamlined, you meet user expectations.

  2. Intermediate Automation

    • CI/CD pipelines handle building, testing, and packaging fairly reliably, with occasional manual steps.

  3. Some Monitoring of SLAs

    • You measure deployment times for important services. If they exceed certain thresholds, you investigate.

  4. Sporadic Improvement Initiatives

    • You occasionally gather feedback from dev teams or ops to tweak the pipeline, but you don’t have a continuous improvement loop.

If this approach satisfies your current workloads and stakeholder demands, you may feel it’s sufficient. However, you could still improve deployment speed, reduce manual overhead, and achieve faster feedback cycles.

How to do better

Below are rapidly actionable ways to enhance your moderate efficiency:

  1. Add Real-Time or Automated Monitoring

  2. Optimise Build and Test Steps

  3. Adopt Infrastructure as Code (IaC)

  4. Implement Rolling or Blue/Green Deployments

    • Reduce downtime and user impact by applying advanced deployment strategies.
    • The more confident you are in your pipeline, the faster you can roll out changes.

  5. Introduce Regular Retrospectives

    • e.g., monthly or bi-weekly sessions to review deployment metrics (average build time, deployment durations).
    • Plan small improvements each cycle—like removing a manual test step or simplifying a build script.

By improving monitoring, optimising test/build steps, adopting IaC, and refining deployment strategies, you make your moderately efficient process even faster and more stable.

Streamlined Processes with Regular Monitoring: Builds and deployments are streamlined and regularly monitored, ensuring that they are completed within reasonable timeframes.

How to determine if this good enough

At this level, your builds and deployments are typically quick (tens of minutes or fewer) and monitored in near real time. You might consider it “good enough” if:

  1. Predictable Release Cycles

    • You release multiple times a week (or more frequently) with minimal disruptions or user complaints.
    • Stakeholders trust the release process.

  2. CI/CD Tools Are Widely Adopted

    • Dev and ops teams rely on a mostly automated pipeline for build, test, and deploy steps.
    • Manual intervention is needed only for critical approvals or exception handling.

  3. Proactive Monitoring

    • You gather metrics on build times, test coverage, deployment frequency, and quickly spot regressions.
    • Reports or dashboards are regularly reviewed by leadership.

  4. Collaboration on Improvement

    • Teams occasionally refine the pipeline or test processes, though not always in a continuous improvement cycle.

If your organisation can reliably deliver updates swiftly, you’ve likely avoided major inefficiencies. Yet there is usually room to refine further, aiming for near real-time feedback and single-digit-minute pipelines.

How to do better

Below are rapidly actionable ways to optimise an already streamlined process:

  1. Expand Shift-Left Testing and Security

  2. Add Automated Rollback or Canary Analysis

  3. Adopt Feature Flags

    • Further speed up deployment by decoupling feature rollout from the actual code release:
      • This allows partial or user-segmented rollouts, improving feedback loops.

  4. Implement Detailed Pipeline Telemetry

    • If you only track overall build/deploy times, gather finer metrics:
      • Time spent in unit tests vs. integration tests, container image builds vs. scanning, environment creation vs. final validations.
    • These insights highlight your next optimisation targets.

  5. Formalise Continuous Improvement

    • Host regular pipeline reviews or “build engineering” sprints.
    • Evaluate changes in build times, error rates, or frequency of hotfixes. Use these insights to plan enhancements.

By infusing advanced scanning, canary release strategies, feature flags, and deeper telemetry into your existing streamlined pipeline, you further reduce risk, speed up feedback, and maintain a high level of operational maturity.

Continual Improvement with Rapid Execution: The organisation has a strong focus on continual improvement and efficiency. 99% of builds and deployments are completed in single-digit minutes, with consistent monitoring and optimisation efforts.

How to determine if this good enough

At this final stage, your builds and deployments are lightning-fast, happening in minutes for most projects. You might consider it “good enough” if:

  1. Highly Automated, Highly Reliable

    • DevOps and security teams trust the pipeline to handle frequent releases with minimal downtime or errors.
    • Manual approval steps exist only for the most sensitive changes, and they’re quick.

  2. Real-Time Monitoring and Feedback

    • You track pipeline performance metrics, code quality checks, and security scans in real time, swiftly adjusting if numbers dip below thresholds.

  3. Continuous Innovation

    • The pipeline is never considered “finished”; you constantly adopt new tools or practices that further reduce overhead or increase confidence.

  4. Robust Disaster Recovery

    • Rapid pipeline execution means quick redeploys in case of failure or environment replication.
    • With single-digit-minute pipelines, rollback or rebuild times are also minimised.

Though exemplary, there’s always an opportunity to embed more advanced practices (e.g., AI/ML for anomaly detection in release metrics) and to collaborate with other public sector entities to share your high-speed processes.

How to do better

Below are rapidly actionable ways to refine a near-optimal pipeline:

  1. Incorporate AI/ML Insights

    • Tools or custom scripts that analyze build logs and deployment results for anomalies or patterns over time:
      • e.g., predicting which code changes may cause test failures, optimising pipeline concurrency.

  2. Expand Multi-Stage Testing and Observability

  3. Share Expertise Across Agencies

    • If your pipeline is among the fastest in the UK public sector, participate in cross-government knowledge-sharing:
      • Offer case studies or presentations at GDS or GovTech events, or collaborate with other agencies for mutual learning.

  4. Fully Integrate Infrastructure and Policy as Code

    • Ensure that not only your app code but also your network, security group, and policy definitions are stored in the pipeline, with automatic checks:
      • This creates a fully self-service environment for dev teams, reducing manual interventions further.

  5. Set Zero-Downtime Deployment Goals

    • If you haven’t already, aim for zero user-impact deployments:
      • e.g., advanced canary or rolling strategies in every environment, with automated rollback if user metrics degrade.

By experimenting with AI-driven pipeline intelligence, chaos engineering, advanced zero-downtime deployment strategies, and cross-department collaboration, you continue pushing the boundaries of high-speed, highly reliable build/deployment processes—reinforcing your position as a leader in efficient operations within the UK public sector.

Keep doing what you’re doing, and consider creating blog posts or internal case studies to document your continuous improvement journey. You can also submit pull requests to this guidance or related public sector best-practice repositories, helping others learn from your approach to fast and dependable build/deployment processes.

How does your organisation monitor and observe its cloud infrastructure and application data?

Reactive and Development-Focused Observation: Observations are primarily made during the development phase or in response to issues, with no continuous monitoring in place.

How to determine if this good enough

At this stage, monitoring is minimal or ad hoc, primarily triggered by developer curiosity or urgent incidents. You might consider it “good enough” if:

  1. Small-Scale, Low-Criticality

    • Your applications or infrastructure handle low-priority workloads with few users, so the cost of more advanced monitoring might feel unjustified.

  2. Occasional Issues

    • Incidents happen rarely, and when they do, developers can manually troubleshoot using logs or ad hoc queries.

  3. No Formal SLAs

    • You haven’t promised end users or other stakeholders strict uptime or performance guarantees, so reactive observation hasn’t caused major backlash.

While this might be workable for small or test environments, ignoring continuous monitoring typically leads to slow incident response, knowledge gaps, and difficulty scaling. In the UK public sector, especially if you handle official or personally identifiable data, a lack of proactive observability is risky.

How to do better

Below are rapidly actionable steps to move from reactive observation to basic continuous monitoring:

  1. Implement Simple Infrastructure Monitoring

  2. Enable Basic Application Logging

  3. Set Up Minimal Alerts

    • e.g., CPU usage > 80% triggers an email, or container restarts exceed a threshold:
      • This ensures you don’t rely purely on user reports for operational awareness.

  4. Document Observability Practices

    • A short wiki or runbook describing how to check logs, which metrics to watch, and who to contact if issues emerge.
    • Even a minimal approach fosters consistency across dev and ops teams.

  5. Schedule a Monitoring Improvement Plan

    • Book a monthly or quarterly checkpoint to discuss any monitoring issues or data from the past period.
    • Decide on incremental enhancements each time.

By adopting basic infrastructure metrics, centralising logs, configuring minimal alerts, and documenting your approach, you shift from purely reactive observation to foundational continuous monitoring.

Basic Monitoring Tools and Manual Checks: Basic monitoring tools are used. Checks are often manual and are not fully integrated across different cloud services.

How to determine if this good enough

Here, your organisation uses straightforward dashboards or partial metrics from various cloud services, but lacks integration or automation. You might consider it “good enough” if:

  1. Steady Workloads, Infrequent Changes

    • Infrastructure or application changes rarely happen, so manual checks remain sufficient to catch typical issues.

  2. Limited Cross-Service Dependencies

    • If your environment is not very complex, you might get away with separate dashboards for each service.

  3. No Urgent Performance or SLA Pressures

    • Although you have some basic visibility, you haven’t seen pressing demands to unify or automate deeper monitoring.

However, as soon as you need a single view into your environment, or if you must detect cross-service problems quickly, relying on manual checks and siloed dashboards can hinder timely responses.

How to do better

Below are rapidly actionable ways to integrate your basic monitoring tools:

  1. Consolidate Metrics in a Central Dashboard

  2. Automate Alerts

    • Replace or supplement manual checks with automated alerts for abnormal spikes or dips:
      • e.g., memory usage, 5xx error rates, queue backlogs, etc.
    • Alerts should reach relevant Slack/Teams channels or an email distribution list.

  3. Introduce Tagging for Correlation

    • If you tag resources consistently, your monitoring tool can group related services:
      • e.g., “Project=ServiceX” or “Environment=Production.”
    • This helps you spot trends across all resources for a specific application.

  4. Document Standard Operating Procedures (SOPs)

    • For each common alert (e.g., high CPU, memory leak), define recommended steps or references to logs for quick troubleshooting.
    • This reduces reliance on guesswork or individual heroics.

  5. Integrate with Deployment Pipelines

    • If you have a CI/CD pipeline, embed a step that checks basic health metrics post-deployment:
      • e.g., if error rates spike after a new release, roll back automatically or alert the dev team.

By consolidating metrics, automating alerts, introducing consistent tagging, and creating SOPs, you reduce manual overhead and gain a more unified picture of your environment, improving response times.

Systematic Monitoring with Alerts: Systematic monitoring is in place with alert systems for potential issues. However, the integration of infrastructure and application data is still developing.

How to determine if this good enough

At this stage, you have systematic monitoring, likely with a range of alerts for infrastructure-level events and some application-level checks. You might consider it “good enough” if:

  1. Reliable Incident Notifications

    • Issues rarely go unnoticed—teams are informed promptly of CPU spikes, database errors, or performance slowdowns.

  2. Moderate Integration

    • You combine some app logs with system metrics, but the correlation might not be seamless.
    • High-level dashboards exist, but deeper analysis might require manually cross-referencing data sources.

  3. SLAs Are Tracked but Not Always Guaranteed

    • You monitor operational metrics that relate to your SLAs, but bridging them with application performance (like user transactions) can be patchy.

If your environment is relatively stable or the partial integration meets day-to-day needs, you may consider it sufficient. However, a more holistic approach can cut troubleshooting time and reduce guesswork.

How to do better

Below are rapidly actionable ways to deepen integration of infrastructure and application data:

  1. Adopt APM (Application Performance Monitoring) Tools

  2. Implement Unified Logging and Metric Correlation

    • Use a logging solution that supports correlation IDs or distributed traces:
      • This helps you pivot from an app error to the underlying VM or container metrics in one step.

  3. Create Multi-Dimensional Alerts

    • Instead of CPU-based alerts alone, combine them with application error rates or queue backlog:
      • e.g., alert only if CPU > 80% AND 5xx errors spike, reducing false positives.

  4. Enable Synthetic Monitoring

    • Set up automated user-journey or transaction tests:
      • If these fail, you know the user experience is impacted, not just backend metrics.

  5. Refine SLA/SLI/SLO

    • If you measure high-level “availability,” break it down into a more precise measure (e.g., 99.9% of user requests under 2 seconds).
    • Align your alerts to these SLOs so your monitoring focuses on real user impact.

By combining APM, correlated logs, synthetic tests, and multi-dimensional alerts, you ensure your teams spot potential issues quickly and tie them directly to user experience, thereby boosting operational effectiveness.

Advanced Monitoring with Partial Integration: Advanced monitoring tools are used, providing more comprehensive data. There’s a degree of integration between infrastructure and application monitoring, but it’s not fully seamless.

How to determine if this good enough

Here, your organisation invests in advanced monitoring or APM solutions, has robust metrics/alerts, and partial correlation across layers (e.g., logs, infrastructure usage, application performance). You might consider it “good enough” if:

  1. Wide Observability Coverage

    • Most services—compute, storage, container orchestration—are monitored, along with main application metrics or user experiences.
    • Teams rarely scramble for data in incidents.

  2. Significant Cross-Data Correlation

    • You can jump from an app alert to relevant infrastructure metrics within the same platform, though some manual steps might remain.

  3. Flexible Dashboards

    • Stakeholders can view customised dashboards that show real-time or near real-time health.

  4. Occasional Gaps

    • Some older systems or sub-services might still lack advanced instrumentation.
    • Full-blown correlation (like linking distributed traces to container CPU usage) might not always be frictionless.

If your advanced tools already deliver quick incident resolution and meet compliance or user demands, your approach might suffice. But full integration could further streamline triaging complex issues.

How to do better

Below are rapidly actionable methods to push partial integration to near full integration:

  1. Enhance Distributed Tracing

  2. Adopt an Observability-First Culture

    • Encourage developers to embed structured logs, custom metrics, and trace headers from day one.
    • This synergy helps advanced monitoring tools build a full picture of performance.

  3. Automate Root Cause Analysis (RCA)

    • Some advanced tools or scripts can identify potential root causes by analyzing correlated data:
      • e.g., pinpoint a failing database node or a memory leak in a specific container automatically.

  4. Refine Alert Thresholds Using Historical Data

    • If you have advanced metrics but struggle with noisy or missed alerts, adjust thresholds based on past trends.
    • e.g., If your memory usage typically runs at 70% baseline, alert at 85% instead of 75% to reduce false positives.

  5. Integrate ChatOps

    • Deliver real-time alerts and logs to Slack/Teams channels. Let teams query metrics or logs from chat directly:
      • e.g., a chatbot that surfaces relevant data for incidents or just-in-time debugging.

By fortifying distributed tracing, adopting an “observability-first” mindset, automating partial root cause analysis, and refining alerts, you close the remaining gaps and strengthen end-to-end situational awareness.

Integrated ‘Single Pane of Glass’ Monitoring: A sophisticated, integrated monitoring system is in place, offering a ‘single pane of glass’ view. This system provides actionable insights from both infrastructure and application data.

How to determine if this good enough

At this top level, your organisation has an advanced platform or combination of tools that unify logs, metrics, traces, and alerts into a cohesive experience. You might consider it “good enough” if:

  1. Full Observability

    • From server CPU usage to request-level app performance, all data is aggregated in near real time, and dashboards elegantly tie them together.

  2. Proactive Issue Detection

    • Teams often find anomalies or performance drifts before they cause incidents.
    • MTTR (Mean Time to Resolution) is very low.

  3. Data-Driven Decision-Making

    • Observability data informs capacity planning, cost optimisation, and reliability improvements.
    • Leadership sees clear reports on how changes affect performance or user experience.

  4. High Automation

    • Beyond alerting, some aspects of remediation or advanced analytics might be automated.

Even so, continuous evolution is possible—particularly in adopting AI/ML-based analytics, implementing even more automated healing, or orchestrating global multi-cloud monitoring.

How to do better

Below are rapidly actionable ways to refine an already integrated “single pane of glass” approach:

  1. Leverage AI/ML-Based Anomaly Detection

  2. Implement Self-Healing

    • If your integrated system detects a consistent fixable issue, automate the remedy:
      • e.g., automatically scale containers or restart a microservice if certain metrics exceed thresholds.
    • Ensure any automated fix logs the action for audit or compliance.

  3. Integrate Observability with ChatOps

    • Offer real-time interactive troubleshooting:
      • e.g., Slack bots that can run queries or “explain” anomalies using your “single pane” data.

  4. Adopt Full Lifecycle Cost and Performance Analysis

    • Link your monitoring data to cost metrics for a holistic view:
      • e.g., seeing how scaling up or out affects not only performance but also budget.
    • This fosters more strategic decisions around resource usage.

  5. Share Observability Insights Across the Public Sector

    • If you’ve achieved a truly integrated solution, document your architecture, the tools you used, and best practices.
    • Present or collaborate with other agencies or local councils, uplifting broader public sector observability.

By harnessing AI-driven detection, automating remediation steps, integrating real-time ChatOps, and linking cost with performance data, you push your advanced single-pane-of-glass monitoring to a new level—enabling near-instant responses and deeper strategic insights.

Keep doing what you’re doing, and consider writing internal blogs or case studies on your observability journey. Submit pull requests to this guidance or other public sector best-practice repositories to help others learn from your experiences with integrated cloud monitoring.

How does your organisation obtain real-time insights and answer business-related questions?

SME Analysis with Limited Data Literacy Understanding: Insights largely depend on subject matter experts who analyze available data and provide answers. These experts, while knowledgeable in their field, may not always have a high level of data literacy, making the process more costly and only point in time, not real-time.

How to determine if this good enough

If your organisation primarily relies on a small group of subject matter experts (SMEs) to interpret raw data and produce insights, you might consider it “good enough” if:

  1. Low Frequency of Data-Driven Questions

    • Your operational or policy decisions rarely hinge on up-to-the-minute insights.
    • Data queries happen sporadically, and a slower manual approach remains acceptable.

  2. Very Specific Domain Knowledge

    • Your SMEs possess deep domain expertise that general reporting tools cannot easily replicate.
    • The data sets are not extensive, so manually correlating them still works.

  3. No Immediate Performance or Compliance Pressures

    • You do not face urgent NCSC or departmental mandates to provide real-time transparency.
    • Stakeholders accept periodic updates from SMEs instead of continuous data streams.

While this may work in smaller, stable environments, relying heavily on a few experts for analysis often creates bottlenecks, raises single-point-of-failure risks, and lacks scalability. Additionally, GOV.UK and NCSC guidance often encourage better data literacy and real-time monitoring for government services.

How to do better

Below are rapidly actionable steps to improve data literacy and real-time insight capabilities:

  1. Provide Basic Data Literacy Training

    • Organise short workshops, possibly in partnership with GOV.UK Data in government guidance or local councils, focusing on:
      • How to read and interpret basic charts or dashboards.
      • Terminology for metrics (e.g., “mean,” “median,” “time series,” “confidence intervals”).
    • This empowers more staff to self-serve on simpler data queries.

  2. Adopt a Simple Visualisation or BI Tool

  3. Pilot a Data Lake or Central Data Repository

  4. Encourage a Data Buddy System

    • Pair domain experts with data-literate staff (or external analysts) who can guide them on structured data approaches.
    • This fosters knowledge transfer and upskills both sides.

  5. Reference Official Guidance on Data Handling

By improving data literacy, introducing a basic BI tool, creating a pilot data repository, and pairing experts with data-savvy staff, you begin reducing your reliance on point-in-time manual analysis. Over time, these steps pave the way for real-time insights.

Basic Reporting Tools with Delayed Insights: The organisation uses basic reporting tools that provide insights, but there is typically a delay in data processing and limited real-time capabilities.

How to determine if this good enough

If your organisation employs a standard BI or reporting tool (e.g., weekly or monthly data refreshes), you might regard it as “good enough” if:

  1. Acceptable Lag

    • Stakeholders generally tolerate the existing delay, as they do not require sub-daily or immediate data.

  2. Modest Data Volume

    • Data sets are not enormous, so overnight or batch processing remains practical for your current use cases.

  3. Basic Audit/Compliance

    • You meet essential compliance with government data handling rules (e.g., anonymising personal data, restricted access for sensitive data), and the time lag doesn’t violate any SLAs.

While functional for monthly or weekly insights, delayed reporting can hinder quick decisions or hamper incident response when faster data is needed. In alignment with GDS Service Manual, near real-time data often improves service iteration.

How to do better

Below are rapidly actionable ways to transition from basic delayed reporting to more timely insights:

  1. Explore Incremental Data Refresh

  2. Add Near Real-Time Dashboards

    • Maintain existing weekly summary reports while layering a near real-time view for critical metrics:
      • e.g., the number of service requests in the last hour or real-time error rates in a public-facing service.

  3. Improve Data Quality Checks

  4. Set Timeliness KPIs

    • e.g., “All critical data sets must be updated at least every 2 hours,” or “System error logs refresh in analytics within 15 minutes.”
    • Over time, strive to meet or improve these targets.

  5. Align with NCSC and NIST Guidance on Continuous Monitoring

With incremental data refreshes, partial real-time dashboards, better data pipelines, and timeliness KPIs, you reduce the gap between data generation and insight delivery, improving responsiveness.

Intermediate Analytics with Some Real-Time Data: A combination of analytics tools is used, offering some real-time data insights, though comprehensive, immediate access is limited.

How to determine if this good enough

In this stage, your organisation has partial real-time analytics for select key metrics, while other data sets update less frequently. You might see it as “good enough” if:

  1. Focused Real-Time Use Cases

    • Critical dashboards (e.g., for incident management or user traffic) provide near real-time data, satisfying immediate operational needs.

  2. Hybrid Approach

    • Some systems remain batch-oriented for complexity or cost reasons, while high-priority services stream data into dashboards.

  3. Occasional Gaps

    • Some data sources or teams still rely on older processes, but you have enough real-time coverage for essential decisions.

If your partial real-time insights effectively meet operational demands and user expectations, it can suffice. However, expanding coverage often unlocks deeper cross-functional analyses and faster feedback loops.

How to do better

Below are rapidly actionable ways to enhance your partially real-time analytics:

  1. Adopt Stream Processing for More Datasets

  2. Consolidate Real-Time Dashboards

  3. Enhance Data Integration

    • If certain data sets remain batch-only, try hybrid ingestion methods:
      • e.g., partial streaming for time-critical fields, scheduled for large historical loads.

  4. Conduct Cross-Team Drills

    • Run mock scenarios (e.g., a surge in user transactions or a security event) to test if real-time analytics allow quick response.
    • Identify where missing or delayed data hampers resolution.

  5. Leverage Gov/Industry Guidance

By increasing stream processing, consolidating dashboards, and expanding real-time coverage to more data sets, you minimise the blind spots in your analytics, enabling faster, more informed decisions across the board.

Advanced Analytics Tools with Broad Real-Time Access: The organisation employs advanced analytics tools that provide broader access to real-time data, enabling quicker insights and decision-making.

How to determine if this good enough

At this level, your organisation invests in robust analytics solutions (e.g., data warehouses, near real-time dashboards, possibly machine learning predictions). You might consider it “good enough” if:

  1. Wide Real-Time Visibility

    • Most or all key data streams update in minutes or seconds, letting staff see live operational trends.

  2. Data-Driven Decision Culture

    • Leadership and teams rely on metrics for day-to-day decisions, verifying progress or pivoting quickly.

  3. Machine Learning or Predictive Efforts

    • You may already run ML models for forecasting or anomaly detection, leveraging near real-time feeds for training or inference.

  4. Sufficient Data Literacy

    • Users outside the data team can navigate dashboards or ask relevant questions, with moderate skill in interpretation.

If you already see minimal delays and strong adoption, you’re likely well-aligned with GOV.UK’s push for data-driven services. Still, full self-service or advanced ML might remain partially underutilised.

How to do better

Below are rapidly actionable ways to refine your advanced real-time analytics:

  1. Enhance Data Federation and Governance

  2. Promote Self-Service BI

    • Offer user-friendly dashboards with drag-and-drop analytics:
      • e.g., enabling policy officers, operation managers, or finance leads to build custom views without waiting on IT.

  3. Incorporate Automated Anomaly Detection

  4. Support Data Literacy Initiatives

  5. Set Real-Time Performance Goals

    • e.g., “90% of operational metrics should be visible within 60 seconds of ingestion.”
    • Routinely track how these goals are met or if data pipelines slow over time, making improvements as needed.

By strengthening data governance, encouraging self-service, adopting automated anomaly detection, and continuing to boost data literacy, you maximise the value of your advanced analytics environment.

Comprehensive Self-Service Dashboarding: A self-service dashboarding capability is in place, offering wide access to various data points and enabling users across the organisation to derive real-time insights independently.

How to determine if this good enough

In this final stage, your organisation has a fully realised self-service analytics environment, with real-time data at users’ fingertips. You might consider it “good enough” if:

  1. High Adoption

    • Most staff, from frontline teams to senior leadership, know how to navigate dashboards or create custom views, significantly reducing reliance on specialised data teams.

  2. Minimal Bottlenecks

    • Data is curated, well-governed, and updated in real-time or near real-time. Users rarely encounter outdated or inconsistent metrics.

  3. Data Literacy Maturity

    • Employees across departments can interpret charts, filter data, and ask relevant questions. The environment supports immediate insights for operational or policy decisions.

  4. Continuous Improvement Culture

    • Dashboards evolve rapidly based on feedback, and new data sets are easily integrated into the self-service platform.

Even at this apex, there might be scope to embed advanced predictive analytics, integrate external data sources, or pioneer AI-driven functionalities that interpret data automatically.

How to do better

Below are rapidly actionable ways to refine self-service real-time insights:

  1. Expand Data Sources and Data Quality

    • Enrich dashboards by integrating external open data or cross-department feeds:

  2. Introduce Natural Language or Conversational Queries

  3. Automate Governance and Access Controls

  4. Integrate Predictive Insights in Dashboards

    • If you have ML models, embed their output directly into the dashboard:
      • e.g., forecasting future usage or risk, highlighting anomalies on live charts.

  5. Foster Cross-department Collaboration

By expanding data sources, enabling natural language querying, automating governance, embedding predictive analytics, and partnering with other agencies, you ensure your comprehensive self-service environment stays at the cutting edge—empowering a data-driven culture in UK public sector organisations.

Keep doing what you’re doing, and consider blogging about your journey toward real-time analytics and self-service dashboarding. Submit pull requests to this guidance or other public sector best-practice repositories to help others learn from your successes in delivering timely, actionable insights.

How does your organisation release updates to its applications and services?

Downtime for Updates: Updates are applied by shutting down production, updating applications in place, and restarting. Rollbacks rely on backups if needed.

How to determine if this good enough

Your organisation might tolerate taking production offline during updates if:

  1. Low User Expectations

    • The service is internal-facing with predictable usage hours, so planned downtime does not disrupt critical workflows.

  2. Simple or Infrequent Releases

    • You rarely update the application, so the cost and user impact of downtime remain acceptable.

  3. Minimal Data Throughput

    • If the application doesn’t handle large volumes of data or real-time requests, a brief outage may not cause serious issues.

However, in the UK public sector environment—where services can be integral for citizens, healthcare, or internal government operations—planned downtime can erode trust and hamper 24/7 service expectations. Additionally, rollbacks relying on backups can be risky if not regularly tested.

How to do better

Below are rapidly actionable steps to transition from downtime-based updates to more resilient approaches:

  1. Pilot a Rolling or Blue/Green Approach

  2. Establish a Basic CI/CD Pipeline

    • So that updates are automated and consistent:
      • e.g., run unit tests, integration checks, and create a deployable artifact with each commit.
    • NCSC’s guidance on DevSecOps or NIST SP 800-160 can inform security integration into the pipeline.

  3. Use Snapshot Testing or Quick Cloning

    • If you remain reliant on backups for rollback, test them frequently:
      • Ensure daily or more frequent snapshots can be swiftly restored in a staging environment to confirm reliability.

  4. Communicate Downtime Effectively

    • If immediate elimination of downtime is not feasible, set up a transparent communication plan:

  5. Aim for Rolling Updates Pilot

    • Identify at least one non-critical service to pilot rolling or partial updates, building confidence for production.

By adopting minimal rolling or staging-based updates, automating deployment pipelines, and ensuring robust backup/restore processes, you reduce the disruptive nature of downtime-based updates—paving the way for more advanced, near-zero-downtime methods.

Rolling Updates During Maintenance Windows: Updates are performed using rolling updates, impacting production capacity to some extent, usually scheduled during maintenance windows.

How to determine if this good enough

At this stage, your organisation has moved past full downtime, using a rolling mechanism that replaces or updates a subset of instances at a time. You might consider it “good enough” if:

  1. Limited User Impact

    • Some capacity is taken offline during updates, but carefully scheduled windows or off-peak hours minimise issues.

  2. Predictable Workloads

    • If your usage patterns allow for stable maintenance windows (e.g., nights or weekends), then capacity hits don’t severely affect performance.

  3. Moderate Release Frequency

    • The organisation has relatively few feature updates, so scheduled windows remain acceptable for user expectations.

While better than full downtime, rolling updates that rely on maintenance windows can still cause disruptions for 24/7 services or hamper urgent patch releases.

How to do better

Below are rapidly actionable improvements:

  1. Implement Automated Health Checks

  2. Adopt a Canary or Blue/Green Strategy for Critical Services

    • Gradually test changes on a small portion of traffic before proceeding:
      • This reduces risk if an update has issues.

  3. Shorten or Eliminate Maintenance Windows

    • If rolling updates are stable, see if you can do them in business hours for services with robust capacity.
    • Communicate frequently with users about partial capacity reductions, referencing relevant GOV.UK operational guidelines.

  4. Automate Rollback

  5. Reference NCSC Guidance on Operational Resilience

By adding health checks, introducing partial canary or blue/green methods, and continuously automating rollbacks, you further minimise the user impact even within a rolling update strategy—potentially removing the need for fixed maintenance windows.

Manual Cut-Over with New Versions: New versions of applications are deployed without impacting existing production, with a manual transition to the new version during a maintenance window. Manual rollback to the previous version is possible if needed.

How to determine if this good enough

This approach is somewhat akin to a blue/green deployment but with a manually triggered cut-over. You might consider it “good enough” if:

  1. Limited Release Frequency

    • You update only occasionally, and a scheduled manual switch is acceptable to your stakeholders.

  2. Manual Control Preference

    • You desire explicit human oversight for compliance or security reasons (e.g., sign-off from a designated manager before cut-over).

  3. Rollback Confidence

    • Retaining the old version running in parallel offers an easy manual fallback if issues arise.

While this drastically reduces downtime compared to in-place updates, manual steps can introduce human error or delay. Over time, automating the cut-over can speed releases and reduce overnight tasks.

How to do better

Below are rapidly actionable ways to enhance manual cut-over processes:

  1. Automate the Switch

  2. Incorporate Automated Testing Pre-Cut-Over

    • Run smoke/integration tests on the new environment before the final switch:
      • If tests pass, you simply approve the cut-over.

  3. Establish Clear Checklists

    • List each step, from final pre-check to DNS swap, ensuring all relevant logs, metrics, or alerts are turned on:
      • Minimises risk of skipping a crucial step during a manual process.

  4. Use Observability Tools for Rapid Validation

    • After switching, verify the new environment quickly with real-time dashboards or synthetic user tests:
      • This helps confirm everything runs well before fully retiring the old version.

  5. Refer to NCSC Operational Resilience Guidance

    • NCSC documentation offers principles for ensuring minimal disruption when switching environments.
    • NIST SP 800-160 Vol 2 can also provide insights on engineering for cyber-resilience in deployment processes.

By automating as many cut-over steps as possible, implementing integrated testing, and leveraging robust observability, you reduce manual overhead while retaining the safety of parallel versions.

Canary or Blue/Green Strategy with Manual Transition: Updates are released using a canary or blue/green strategy, allowing manual transition between current and new versions. Formal maintenance windows are not routinely necessary.

How to determine if this good enough

Here, your organisation uses modern deployment patterns (canary or blue/green) but triggers the actual traffic shift manually. You might consider it “good enough” if:

  1. High Control Over Releases

    • Your ops or dev team can watch key metrics (error rates, performance) before deciding to cut fully.
    • Reduces risk of automated changes if something subtle goes wrong.

  2. Flexible Schedules

    • You’re no longer constrained by a formal maintenance window, as the environment runs both old and new versions.
    • You only finalise the transition once confidence is high.

  3. Minimal User Impact

    • Users experience near-zero downtime, with only a potential brief session shift if done carefully.

If your manual step ensures a safe release, meets compliance requirements for sign-off, and you have the capacity to staff this process, it can be fully viable. However, further automation can accelerate releases, especially if you deploy multiple times daily.

How to do better

Below are rapidly actionable methods to enhance manual canary or blue/green strategies:

  1. Automate Traffic Shaping

  2. Implement Automated Rollback

    • If metrics degrade beyond thresholds, revert automatically to the stable version without waiting for manual action:
      • e.g., a pipeline checking real-time error rates or latency.

  3. Adopt Observability-Driven Deployment

    • Use real-time logging, metrics, and user experience monitoring to confirm if the new version is healthy:

  4. Enhance Developer Autonomy

    • If your policy allows, let smaller updates or patch releases auto-deploy after canary checks pass, reserving manual oversight only for major changes or high-risk deployments.

  5. Consider ChatOps or Tools for One-Click Approvals

    • Slack/Teams integrated pipeline steps let authorised personnel type a simple command or press a button to shift traffic from old to new version.
    • This lowers friction while preserving manual control.

By introducing traffic shaping with partial auto-deploy or rollback, deeper observability, and flexible chat-based control, you refine your canary or blue/green approach, reducing the manual overhead of each release while keeping high confidence.

Dynamic Canary/Blue/Green Strategy without Maintenance Windows: Updates are managed via a canary or blue/green strategy with dynamic transitioning of users between versions. This approach eliminates the need for formal maintenance windows.

How to determine if this good enough

At this pinnacle, your organisation deploys new versions seamlessly, shifting traffic automatically or semi-automatically. You might consider it “good enough” if:

  1. Continuous Deployment

    • You can safely release multiple times a day with minimal risk.
    • Pipeline-driven checks ensure swift rollback if anomalies arise.

  2. Zero Downtime

    • Users rarely notice updates—there are no enforced windows or service interruptions.

  3. Real-Time Feedback

    • Observability tools collect usage metrics and error logs, auto-deciding if further rollout is safe.
    • Manual intervention is minimal except for major changes or exceptional circumstances.

  4. Strong Compliance & Audit Trails

    • Each release is logged, including canary results, ensuring alignment with NCSC operational resilience guidance or internal audit requirements.
    • This meets or exceeds NIST guidelines for continuous monitoring and secure DevOps.

If you’ve reached near-instant deployments, zero-downtime strategies, and robust monitoring, your process is highly mature. You still might push further into A/B testing or advanced ML-driven optimisation.

How to do better

Even at this top maturity level, there are rapidly actionable improvements:

  1. Expand Automated Testing & AI/ML Analysis

  2. Implement Feature Flag Management

    • Decouple feature releases from deployments entirely:
      • e.g., changing user experience or enabling new functionality with toggles, tested gradually.
    • Tools like [LaunchDarkly], or vendor-based solutions [AWS AppConfig feature flags, Azure Feature Management, GCP Feature Flags, or OCI-based toggles] can help.

  3. Advance Security & Testing

  4. Explore Multi-Cluster or Multi-Region Failover

    • If one region or cluster is updating, route traffic to another fully operational cluster for absolute minimal disruption:
      • This further cements zero downtime across a national or global footprint.

  5. Collaborate with Other Public Sector Bodies

    • Share your near-instant, zero-downtime deployment patterns with local councils or other departments:

By embedding advanced anomaly detection, feature flag strategies, multi-region failover, and deepening security checks, you maintain a cutting-edge continuous deployment ecosystem—aligning with top-tier operational excellence in the UK public sector.

Keep doing what you’re doing, and consider documenting your advanced release strategies in internal or external blog posts. You can also submit pull requests to this guidance or other public sector best-practice repositories, helping others progress toward zero-downtime, high-confidence release methods.

How is your deployment and QA pipeline structured?

Manual Scheduled QA Process: Deployment and QA are handled through a manually scheduled process, lacking automation and continuous integration.

How to determine if this good enough

In this stage, your organisation relies on human-driven steps (e.g., emailing code changes to QA testers, manual approval boards, or ad hoc scripts) for both deployment and testing. You might consider it “good enough” if:

  1. Very Limited Release Frequency

    • You update your applications once every few months, and thus can handle manual overhead without major inconvenience.

  2. Low Criticality

    • The services do not require urgent patches or security updates on short notice, so the lack of continuous integration poses minimal immediate risk.

  3. Simplicity and Stability

    • The application is relatively stable, and major functional changes are rare, making manual QA processes manageable.

However, manual scheduling severely limits agility and can introduce risk if errors go unnoticed due to a lack of automated testing. For many UK public sector services, NCSC guidelines encourage more frequent updates and better security practices, which usually involve continuous integration.

How to do better

Below are rapidly actionable steps to move beyond entirely manual QA and deployments:

  1. Introduce a Simple CI Pipeline

  2. Document a Standard Release Checklist

    • Ensure each deployment follows a consistent procedure, covering essential steps like code review, environment checks, and sign-off by the project lead.

  3. Schedule a Pilot for Automated QA

    • If you typically rely on manual testers, pick a small piece of your test suite to automate:
      • e.g., smoke tests or a top-priority user journey.
    • This pilot can demonstrate the value of automation to stakeholders.

  4. Set Clear Goals for Reducing Manual Steps

    • Aim to reduce “time to deploy” or “time spent on QA” by a certain percentage over the next quarter, aligning with agile or DevOps improvement cycles recommended by GOV.UK Service Manual practices.

  5. Review Security Compliance

By establishing minimal CI automation, clarifying release steps, and piloting automated QA, you build confidence in incremental improvements, setting the foundation for more robust pipelines.

Basic Automation with Infrequent Deployments: Some level of automation exists in the QA process, but deployments are infrequent and partially manual.

How to determine if this good enough

If your organisation has introduced some automated tests or a partial CI pipeline (e.g., unit tests running on commits), yet still deploys rarely or with manual checks, you might find it “good enough” if:

  1. Low or Medium Release Velocity

    • Even with some test automation, you prefer scheduled or larger releases rather than continuous iteration.

  2. Limited Immediate Risk

    • The application can handle occasional updates without strong demands for real-time patches or new features.

  3. Stable Funding or Resource Constraints

    • You have a moderate DevOps or QA budget, which doesn’t push for fully automated, frequent deployments yet.

While partial automation improves reliability, infrequent deployments may slow responses to user feedback or security issues. NCSC guidance on secure system development encourages a faster feedback loop to patch vulnerabilities promptly.

How to do better

Below are rapidly actionable methods to evolve from partial automation:

  1. Expand Automated Tests to Integration or End-to-End (E2E)

  2. Adopt a More Frequent Release Cadence

    • Commit to at least monthly or bi-weekly releases, allowing you to discover issues earlier and respond to user needs faster.

  3. Introduce Automated Rollback or Versioning

  4. Refine Manual Approvals

    • If manual gates remain, streamline them with a single sign-off or Slack-based approvals rather than long email chains:
      • This ensures partial automation doesn’t stall at a manual step for days.

  5. Consult NIST SP 800-53

    • Evaluate recommended controls for software release (CM-3, SA-10) and integrate them into your pipeline for better compliance documentation.

By broadening test coverage, increasing release frequency, and automating rollbacks, you lay the groundwork for more frequent, confident deployments that align with modern DevOps practices.

Integrated Deployment and Regular QA Checks: Deployment is integrated with regular QA checks, featuring a moderate level of automation and consistency in the pipeline.

How to determine if this good enough

In this scenario, your pipelines are well-defined. Automated tests run for each build, and you have a consistent process connecting deployment to QA. You might judge it “good enough” if:

  1. Predictable Release Cycles

    • You typically deploy weekly or bi-weekly, and your environment has minimal issues.

  2. Moderately Comprehensive Testing

    • You have decent coverage across unit, integration, and some acceptance tests.

  3. Stable or Evolving DevOps Culture

    • Teams trust the pipeline, and it handles the majority of QA checks automatically, though some manual acceptance or security tests might remain.

If your current approach reliably meets user demands and mitigates risk, it can suffice. Yet you can usually speed up feedback and further reduce manual overhead by adopting advanced CI/CD techniques.

How to do better

Below are rapidly actionable ways to enhance integrated deployment and QA:

  1. Add Security and Performance Testing

  2. Implement Parallel Testing or Test Suites

    • If test execution time is long, parallelise them:
      • e.g., AWS CodeBuild parallel builds, Azure Pipelines multi-job phases, GCP Cloud Build multi-step concurrency, or OCI DevOps parallel test runs.

  3. Introduce Slack/Teams Notifications

    • Notify dev and ops channels automatically about pipeline status, test results, and potential regressions:
      • Encourages quick fixes and fosters a more collaborative environment.

  4. Adopt Feature Flag Approaches

    • Deploy new code continuously but hide features behind flags:
      • This ensures “not fully tested or accepted” features remain off for end users until QA sign-off.

  5. Reference GOV.UK and NCSC

By strengthening security/performance checks, parallelising tests, using real-time notifications, and employing feature flags, you further streamline your integrated QA pipeline while maintaining robust checks and balances.

CI/CD with Automated Testing: A Continuous Integration/Continuous Deployment (CI/CD) pipeline is in place, including automated testing and frequent, reliable deployments.

How to determine if this good enough

Here, your organisation relies on a sophisticated, automated pipeline that runs on every code commit or merges. You might consider it “good enough” if:

  1. High Release Frequency

    • Deployments can happen multiple times a week or day with minimal risk.

  2. Robust Automated Testing

    • Your pipeline covers unit, integration, functional, and security tests, with little reliance on manual QA steps.

  3. Low MTTR (Mean Time to Recovery)

    • Issues discovered post-deployment can be quickly rolled back or patched, reflecting a mature DevOps culture.

  4. Compliance and Audit-Friendly

Even so, you may refine or extend your pipeline (e.g., ephemeral testing environments, advanced canary releases, or ML-based anomaly detection in logs) to further boost agility and reliability.

How to do better

Below are rapidly actionable ways to refine your existing CI/CD with automated testing:

  1. Shift Left Security

    • Embed security tests (SAST, DAST, license compliance) earlier in the pipeline:
      • e.g., scanning pull requests or pre-merge checks for known vulnerabilities.

  2. Adopt Canary/Blue-Green Deployments

  3. Implement Automated Rollback

    • If user impact or error rates spike post-deployment, revert automatically to the previous version without manual steps.

  4. Use Feature Flags for Safer Experiments

    • Deploy code continuously but toggle features on gradually.
    • This approach de-risks large releases and speeds up delivery.

  5. Encourage Cross-Government Collaboration

By deepening security integration, adopting advanced deployment tactics, and refining rollbacks or feature flags, you enhance an already stable CI/CD pipeline. This leads to even faster, safer releases aligned with top-tier DevSecOps practices recommended by NCSC and NIST.

On-Demand Ephemeral Environments: Deployment and QA utilise short-lived, ephemeral environments provisioned on demand, indicating a highly sophisticated, efficient, and agile pipeline.

How to determine if this good enough

At this top maturity level, your pipelines can spin up full-stack test environments for each feature branch or bug fix, and once tests pass, they’re torn down automatically. You might consider it “good enough” if:

  1. High Flexibility, Minimal Resource Waste

    • QA can test multiple features in parallel without overhead of long-lived staging environments.

  2. Extremely Fast Feedback Loops

    • Developers receive near-instant validation that their changes work end-to-end.

  3. Advanced Automation and Observability

    • The pipeline not only provisions environments but also auto-injects test data, runs comprehensive tests, and collects logs/metrics for quick analysis.

  4. Seamless Integrations

    • Data security, user auth, or external services are seamlessly mocked or linked without complex manual steps.

While ephemeral environments typically reflect leading-edge DevOps, there’s always scope for refining cost efficiency, improving advanced security automation, or further integrating real-time analytics.

How to do better

Even at this apex, there are rapidly actionable improvements:

  1. Adopt Policy-as-Code for Environment Provisioning

  2. Automated Data Masking or Synthetic Data

    • If ephemeral environments need real data, ensure compliance with UK data protection regs:
      • Use synthetic test data or anonymise production copies to maintain NCSC data security best practices.

  3. Inject Chaos or Performance Tests

    • Incorporate chaos engineering (e.g., random container/network failures) and load tests in ephemeral environments:
      • This ensures high resilience under real-world stress.

  4. Optimise Environment Lifecycle

    • Monitor resource usage to avoid ephemeral environments lingering longer than needed:
      • e.g., automatically tear down environments if no activity is detected after 48 hours.

  5. Collaborate with UK Gov or Local Councils

By embedding policy-as-code, securing data in ephemeral environments, introducing chaos/performance tests, and aggressively managing environment lifecycles, you ensure your pipeline remains at the cutting edge—fully aligned with advanced DevOps capabilities recommended by NCSC, NIST, and other relevant bodies.

Keep doing what you’re doing, and consider writing up your experiences or creating blog posts about your ephemeral environment successes. You can also submit pull requests to this guidance or other public sector best-practice repositories, helping others in the UK public sector evolve their QA pipelines and deployment processes.

How is your organisation structured to develop and implement its cloud vision and strategy?

No Dedicated Cloud Team: There is no specific team focusing on cloud strategy; teams operate in silos based on traditional, on-premises role definitions.

How to determine if this good enough

Your organisation may run cloud operations without a formal cloud-oriented structure, relying on legacy or on-prem roles. This might be considered “good enough” if:

  1. Low Cloud Adoption

    • You only use minimal cloud services for pilot or non-critical workloads, making specialised cloud roles seem unnecessary.

  2. Stable or Limited Growth

    • Infrastructure demands rarely change, so a dedicated cloud team is not yet recognised as a priority.

  3. No Formal Strategy

    • Senior leadership or departmental heads are content with the status quo. No urgent requirement (e.g., cost optimisation, advanced digital services) drives a need for specialised cloud skills.

However, lacking a dedicated cloud focus often results in uncoordinated efforts, missed security best practices, and slow adoption of modern technologies. NCSC cloud security guidelines encourage establishing clear accountability and specialised skills for public sector cloud operations.

How to do better

Below are rapidly actionable steps to start formalising a cloud-oriented approach:

  1. Identify a Cloud Advocate

  2. Host Internal Workshops

  3. Create a Cloud Starter Doc

  4. Pilot a Small Cross-Functional Team

    • If you have an upcoming project with cloud components, assemble a temporary team from different departments (development, security, finance) to coordinate on cloud decisions.

  5. Define Basic Cloud Roles

    • Even without a dedicated cloud team, define who handles security reviews, cost optimisation checks, or architectural guidance.

By designating a cloud advocate, introducing basic cloud knowledge sessions, and forming a small cross-functional group for a pilot project, you lay the groundwork for a more coordinated approach to cloud strategy and operations.

Informal Cloud Expertise: Informal groups or individuals with cloud expertise exist, facilitating some degree of cross-organisational collaboration.

How to determine if this good enough

When some staff have cloud knowledge and organically help colleagues, your organisation achieves partial cloud collaboration. This may be “good enough” if:

  1. Moderate Cloud Adoption

    • You already operate a few production workloads in the cloud, and ad hoc experts resolve issues or give guidance sufficiently well.

  2. Flexible Culture

    • Teams are open to sharing cloud tips and best practices, but there’s no formal structure or authority behind it.

  3. No Pressing Need for Standardisation

    • Departments might be content with slight variations in cloud usage as long as top-level goals are met.

While better than complete silos, purely informal networks can cause challenges in scaling solutions, ensuring consistent security measures, or presenting a cohesive cloud vision at the organisational level.

How to do better

Below are rapidly actionable ideas to strengthen informal cloud expertise:

  1. Formalise a Community of Practice

  2. Create a Shared Knowledge Base

  3. Encourage One-Stop Repos

    • For repeated patterns (e.g., Terraform templates for secure VMs or container deployments), maintain a Git repo that all teams can reference.

  4. Promote Shared Governance

    • Align on a minimal set of “must do” controls (e.g., mandatory encryption, logging).
    • Consider referencing NIST SP 800-53 controls for cloud resource security responsibilities.

  5. Pilot a Small Formal Working Group

    • If informal collaboration works well, create a small “Cloud Working Group” recognised by leadership.
    • They can propose consistent patterns or cost-saving tips for cross-team usage.

By forming a community of practice, establishing a knowledge base, and beginning minimal governance alignment, you transition from ad hoc experts toward a more structured, widely beneficial cloud strategy.

Formal Cross-Functional Cloud Team/COE: A formal Cloud Center of Excellence or equivalent cross-functional team exists, providing foundational support and guidance for cloud operations.

How to determine if this good enough

At this stage, you’ve established a Cloud Center of Excellence (COE) or similar body that offers resources, best practices, and guidelines for cloud usage. It may be “good enough” if:

  1. Visibility and Authority

    • The COE is recognised by senior management or departmental leads, shaping cloud-related decisions across the organisation.

  2. Standardised Practices

    • The COE maintains patterns for infrastructure as code, security baselines, IAM policies, and cost optimisation.
    • Teams typically consult these guidelines for new cloud projects.

  3. Growing Cloud Adoption

    • The COE’s existence accelerates confident use of cloud resources, boosting agility without sacrificing compliance.

If the COE is well-integrated and fosters consistent cloud usage, it might suffice. However, you can further embed COE standards into daily workflows or empower product teams with more autonomy.

How to do better

Below are rapidly actionable strategies to improve a formal Cloud COE:

  1. Offer Self-Service Catalogs or Templates

  2. Extend COE Services

    • e.g., specialised security reviews, compliance checks referencing NCSC 14 Cloud Security Principles, or cost optimisation workshops that unify departmental approaches.

  3. Set up a Community of Practice

    • Have the COE coordinate monthly open sessions for all cloud practitioners to discuss new vendor features, success stories, or security enhancements.

  4. Embed COE Members in Key Projects

    • Provide “COE ambassadors” who temporarily join project teams to share knowledge and shape architecture from the start.

  5. Consult NIST and GOV.UK for Strategy Guidance

By delivering self-service solutions, deeper security reviews, and an active cloud community, the COE matures into a vital driver for consistent, secure, and cost-effective cloud adoption across the organisation.

Integrated Cloud Teams Following COE Standards: Cloud teams across the organisation follow standards and patterns established by the Cloud COE. Cross-functional roles are increasingly common within development teams.

How to determine if this good enough

Here, the COE’s guidance and patterns have been widely adopted. Project-specific cloud teams incorporate cross-functional roles (e.g., security, networking, DevOps). You might see it as “good enough” if:

  1. Unified Governance

    • Nearly all new cloud deployments adhere to COE-sanctioned architectures, security configurations, and cost policies.

  2. Broad Collaboration

    • Teams across the organisation share knowledge, follow standard templates, and integrate cloud best practices early in development.

  3. Accelerated Delivery

    • Because each project leverages proven patterns, time to deliver new cloud-based services is significantly reduced.

Still, certain advanced areas—like fully autonomous product teams or dynamic ephemeral environments—might remain underutilised, and you might expand the COE’s influence further.

How to do better

Below are rapidly actionable steps to further integrate the COE’s standards into everyday operations:

  1. Adopt “Cloud-First” or “Cloud-Smart” Policies

    • Mandate that new solutions default to cloud-based approaches unless there’s a compliance or cost reason not to.
    • Reference relevant policy from GOV.UK’s Cloud First policy for alignment.

  2. Introduce Automated Compliance Checks

  3. Enable On-Demand Cloud Labs/Training

    • Provide hands-on workshops or sandbox accounts where staff can experiment with new cloud services in a safe environment.
    • Encourages further skill growth and cross-pollination.

  4. Measure Outcomes and Iterate

    • Track success metrics: e.g., time to provision environments, frequency of security incidents, cost savings realised by standard patterns.
    • Present these metrics in monthly or quarterly leadership updates, aligning with NCSC operational resilience guidance.

  5. Improve Cross-Functional Team Composition

    • Incorporate security engineers and cloud architects directly into product squads for new digital services, reducing handoffs.

By mandating automated compliance checks, fostering a “cloud-first” approach, expanding skill-building labs, and embedding security/architecture roles into each delivery team, you further entrench consistent, effective cloud usage across the public sector organisation.

Advanced Cloud COE Operating Model: The Cloud COE has matured into a comprehensive operating model with fully autonomous, cross-functional teams that include experts in all necessary technology and process domains.

How to determine if this good enough

At this final stage, you have a highly sophisticated COE model where product teams are fully empowered with cloud skills, processes, and governance. You might consider it “good enough” if:

  1. High Autonomy, Low Friction

    • Teams can spin up secure, cost-efficient cloud resources independently, referencing well-documented patterns, without bottlenecks or repeated COE approvals.

  2. Robust Governance

    • The COE remains a guiding entity rather than a gatekeeper, ensuring continuous compliance with NCSC guidelines or NIST standards via automated controls.

  3. Continuous Innovation

    • Because cross-functional teams handle security, DevOps, architecture, and user needs holistically, new services roll out quickly and reliably.

  4. Data-Driven & Secure

    • Cost usage, security posture, and performance metrics are all visible organisation-wide, enabling proactive decisions and swift incident response.

Though you’re at an advanced state, ongoing adaptation to new cloud technologies, security challenges, or legislative updates remains crucial for sustained leadership in digital transformation.

How to do better

Below are rapidly actionable ways to refine an already advanced operating model:

  1. Introduce FinOps Practices

  2. Enable Self-Service Data & AI

    • If each product team can not only provision compute but also harness advanced analytics or ML on demand:
      • Speeds up data-driven policy or service improvements.

  3. Adopt Policy-as-Code

    • Extend your automated governance:
      • e.g., using [Open Policy Agent (OPA) or AWS Service Control Policies, Azure Policy, GCP Organisation Policy, or OCI Security Zones] to ensure consistent rules across the entire estate.

  4. Engage in Cross-Government Collaboration

    • Share your advanced COE successes with other departments, local councils, or healthcare orgs:
      • Possibly present at GOV.UK community meetups, or work on open-source infrastructure modules that other public bodies can reuse.

  5. Stay Current with Tech and Security Trends

    • Periodically assess new NCSC or NIST advisories, cloud vendor releases, or best-practice updates to keep your operating model fresh, secure, and cost-effective.

By incorporating robust FinOps, self-service AI, policy-as-code, cross-government collaboration, and continuous trend analysis, you ensure your advanced COE model remains at the forefront of effective and secure cloud adoption in the UK public sector.

Keep doing what you’re doing, and consider writing blog posts or internal knowledge-sharing articles about your advanced Cloud COE. Submit pull requests to this guidance or other public sector best-practice repositories to help others learn from your successes in structuring cross-functional cloud teams and ensuring an effective operating model.

What is the structure of your organisation in terms of managing cloud operations?

Developer-Managed Cloud Operations: There is no dedicated cloud team; application developers are responsible for managing all aspects of cloud operations.

How to determine if this good enough

If developers handle cloud deployments, architecture, security, and day-to-day management without a specialised cloud team, you might consider it “good enough” if:

  1. Small, Simple Environments

    • The cloud footprint is minimal, with one or two services that developers can handle without overhead.

  2. Low Operational Complexity

    • The services don’t require advanced resilience, multi-region failover, or intricate compliance demands.
    • Developer skill sets are adequate to manage basic cloud tasks.

  3. Limited Budget or Staffing

    • Your department lacks the resources to form a dedicated cloud or DevOps team, and you can handle ongoing operations with the existing developer group.

However, if your environment grows or demands 24/7 uptime, developer-led ops can hinder productivity and conflict with advanced security or compliance best practices recommended by NCSC or NIST SP 800-53.

How to do better

Below are rapidly actionable steps to move beyond developer-exclusive cloud management:

  1. Form a DevOps Guild or Community of Practice

  2. Introduce Minimal Automated Monitoring & Alerts

  3. Implement Basic Infrastructure as Code

  4. Add a Cloud Security Checklist

  5. Request Budget or Headcount

    • If workloads grow, advocate for dedicated cloud engineering staff. Present cost/risk benefits to leadership, referencing GOV.UK cloud-first policy and potential agility gains.

By fostering a DevOps guild, adding automated monitoring, adopting IaC, and pushing for minimal security guidelines, you gradually evolve from purely developer-led ops to a more stable, repeatable cloud operation that can scale.

Fully Outsourced Cloud Operations and Strategy: All cloud operations, including the definition of strategic direction, are outsourced to a third-party supplier.

How to determine if this good enough

When all aspects of cloud—deployment, maintenance, security, strategy—are handled by an external vendor, you might consider it “good enough” if:

  1. Limited Internal Capacity

    • You do not have the in-house resources or time to recruit a dedicated cloud team.
    • Outsourcing meets immediate needs without major overhead.

  2. Tight Budget

    • The contract with an external supplier may appear cost-effective at present, covering both ops and strategic planning.

  3. Stable Workloads

    • Your environment rarely changes, so a third-party can manage updates or occasional expansions without heavy internal oversight.

However, outsourcing strategic direction can leave the organisation dependent on external decisions, potentially misaligned with your departmental goals or public sector guidelines. NCSC’s recommendations often emphasize maintaining a degree of internal oversight for security and compliance reasons.

How to do better

Below are rapidly actionable ways to balance outsourced support with internal ownership:

  1. Retain Strategic Oversight

    • Even if operations remain outsourced, designate an internal “Cloud Lead” or small working group responsible for governance and security:

  2. Set Clear SLA and KPI Requirements

    • Make sure the vendor’s contract outlines response times, compliance with GOV.UK Cloud Security Principles or NCSC best practices, and regular cost-optimisation reviews.

  3. Insist on Transparent Reporting

    • Request routine dashboards or monthly metrics on performance, cost, security events.
    • Ask the vendor to integrate with your chosen monitoring tools if possible.

  4. Plan a Knowledge Transfer Path

    • Negotiate with the vendor to provide training sessions or shadowing opportunities, building internal cloud literacy:
      • e.g., monthly knowledge-sharing on cost optimisation or security patterns.

  5. Retain Final Decision Power on Strategic Moves

    • The vendor can propose solutions, but major platform changes or expansions should get internal review for alignment with departmental objectives.
    • This ensures the outsourced arrangement doesn’t override your broader digital strategy.

By keeping strategic authority, setting stringent SLAs, fostering vendor-provided knowledge transfer, and maintaining transparent reporting, you reduce vendor lock-in and ensure your cloud approach aligns with public sector priorities and compliance expectations.

Outsourced Operations with Internal Strategic Ownership: Cloud operations are outsourced, but the strategic direction for cloud usage is developed and owned internally by the department.

How to determine if this good enough

Here, your organisation retains the cloud vision and strategy, while day-to-day ops remain outsourced. It might be “good enough” if:

  1. High-Level Control

    • You define the roadmap (e.g., which services to adopt, target costs, security posture), while the vendor handles operational execution.

  2. Alignment with Department Goals

    • Because strategy is owned internally, solutions remain consistent with your policy, user needs, and compliance.

  3. Balanced Resource Usage

    • Outsourcing ops can reduce staff overhead, allowing your in-house team to focus on strategic or domain-specific tasks.

If this arrangement effectively supports agile improvements, meets cost targets, and respects data security guidelines (from NCSC or NIST SP 800-53)—while you retain final say on direction—then it can suffice. But you can enhance synergy and reduce possible knowledge gaps further.

How to do better

Below are rapidly actionable enhancements:

  1. Co-Create Operational Standards

  2. Embed Vendor Staff into Internal Teams

    • If feasible, have vendor ops staff attend your sprint reviews or planning sessions, improving communication and reducing friction.

  3. Establish Regular Strategic Review

    • Conduct quarterly or monthly reviews to align on:
      • Future cloud services adoption
      • Cost optimisation opportunities
      • Evolving security or compliance needs

  4. Request Real-Time Metrics

    • Ensure the vendor’s operational data (e.g., cost usage, performance dashboards) is accessible to your internal strategic leads:
      • e.g., a shared AWS Cost Explorer or Azure Cost Management view for weekly usage checks.

  5. Plan for Potential In-House Expansion

    • If usage grows or departmental leadership wants more direct control, negotiate partial insourcing of key roles or knowledge transfer from the vendor.

By jointly defining an operations handbook, integrating vendor ops staff in your planning, reviewing strategy regularly, and retaining real-time metrics, you strengthen internal leadership while enjoying the convenience of outsourced operational tasks.

Hybrid Approach with Outsourced Augmentation: A mix of in-house and outsourced resources is used. Third-party suppliers provide additional capabilities (e.g., on-call support), while strategic cloud direction is led by departmental leaders.

How to determine if this good enough

When you blend internal expertise with external support—for instance, your staff handle architecture and day-to-day governance, while a vendor offers specialised services—this arrangement can be “good enough” if:

  1. Flexible Resource Allocation

    • You can easily scale up external help for advanced tasks (e.g., HPC workloads, complex migrations) or 24/7 on-call coverage without overstaffing internally.

  2. Strong Collaboration

    • Regular communication ensures your internal team remains involved, learning from the vendor’s advanced capabilities.

  3. Cost-Effective

    • Outsourcing only targeted areas (e.g., overnight ops or specialised DevOps) while your team handles strategic decisions can keep budgets manageable and transparent.

However, inconsistent processes between internal staff and vendor resources can cause friction or confusion about accountability. NCSC’s guidance on supplier assurance often emphasizes the importance of well-defined contracts and security alignment.

How to do better

Below are rapidly actionable ways to optimise the hybrid approach:

  1. Standardise Tools and Processes

  2. Define Clear Responsibilities

    • For each area (e.g., incident management, security patching, cost reviews), specify whether the vendor or in-house staff leads.
    • Consult NCSC’s supply chain security guidance to ensure robust accountability.

  3. Integrate On-Call Rotations

    • If the vendor provides 24/7 coverage, have an internal secondary on-call or bridging approach:
      • This fosters knowledge exchange and ensures no single point of failure if the vendor struggles.

  4. Align on a Joint Roadmap

    • Create a 6-12 month cloud roadmap, listing major initiatives like infrastructure refreshes, security enhancements (e.g., compliance with NIST SP 800-53 controls), or cost optimisation steps.

  5. Encourage Cross-Training

    • Rotate vendor staff into internal workshops or hackathons, and have your staff occasionally shadow vendor experts to deepen in-house capabilities.

By unifying tools, clarifying roles, rotating on-call duties, aligning on a roadmap, and cross-training, you make the hybrid model more cohesive—maximising agility and ensuring consistent cloud operation standards across internal and outsourced teams.

Dedicated In-House Cloud Team: A robust, dedicated cloud team exists within the organisation, comprising at least 5 civil/public servant employees per cloud platform. This team has a shared roadmap for cloud capabilities, adoption, and migration.

How to determine if this good enough

If your organisation has an in-house cloud team for each major platform (e.g., AWS, Azure, GCP, Oracle Cloud), or at least one broad team covering multiple platforms, you might consider it “good enough” if:

  1. Comprehensive Expertise

    • Your staff includes architects, DevOps engineers, security specialists, and cost analysts, ensuring all critical angles are covered.

  2. Clear Organisational Roadmap

    • A well-defined strategy for cloud migration, new service adoption, cost optimisation, or security posture, shared by leadership.

  3. Strong Alignment with Public Sector Objectives

  4. High Independence

    • The team can rapidly spin up new projects, respond to incidents, and deliver advanced capabilities without external vendor lock-in.

Though at a high maturity level, ongoing improvements in team structure, cross-functional collaboration with developer squads, or advanced innovation remain possible.

How to do better

Below are rapidly actionable ways to refine an already dedicated in-house cloud team:

  1. Adopt a DevSecOps Center of Excellence (COE)

    • Evolve your cloud team into a central repository for best practices, security frameworks, and ongoing training:
      • Provide guidelines on ephemeral environments, compliance-as-code, or advanced ML operations.

  2. Set Up Autonomous Product Teams

    • Embed cloud team members directly into product squads, letting them self-manage infrastructure and pipelines with minimal central gatekeeping:
      • This fosters agility while the central team maintains overarching governance.

  3. Implement Policy-as-Code and FinOps

  4. Champion Innovations

    • Keep experimenting with advanced features (e.g., AWS Graviton, Azure confidential computing, GCP Anthos multi-cloud, or OCI HPC offerings) to continuously optimise performance and cost.

  5. Regularly Review and Update the Roadmap

By embedding security and cost best practices, enabling cross-functional product teams, instituting policy-as-code, and continually updating your roadmap, your dedicated in-house cloud team evolves into a dynamic, cutting-edge force that consistently meets UK public sector operational and compliance demands.

Keep doing what you’re doing, and consider writing up your experiences or publishing blog posts on your cloud team’s journey. Also, contribute pull requests to this guidance or similar public sector best-practice repositories, helping others evolve their organisational structures for effective cloud operations.

What is your organisation's approach to planning and preparing for incident response?

Ad-Hoc and Basic Efforts: Incident response is primarily ad-hoc, with some basic efforts in place but no formalised plan or structured approach.

How to determine if this good enough

If your organisation responds to incidents (e.g., system outages, security breaches) in an improvised manner—relying on a few knowledgeable staff with no documented plan—you might consider it “good enough” if:

  1. Few or Infrequent Incidents

    • You have a small, stable environment where major disruptions are rare, so ad-hoc responses haven’t caused major negative impacts or compliance issues.

  2. Low-Risk Services

    • The application or data in question is not critical to citizen services or departmental operations.
    • Failure or compromise does not pose significant security or privacy risks.

  3. Very Limited Resources

    • Your team lacks the time or budget to formalise a plan, and you can handle occasional incidents with minimal fuss.

However, purely ad-hoc responses often lead to confusion, slower recovery times, and higher risk of mistakes. NCSC’s incident management guidance and NIST SP 800-61 on Computer Security Incident Handling recommend having at least a documented process to ensure consistent, timely handling.

How to do better

Below are rapidly actionable steps to move beyond ad-hoc incident response:

  1. Draft a Simple Incident Response (IR) Checklist

  2. Identify Key Roles

    • Even if you can’t create a full incident response team, designate an incident lead and a communications point of contact.
    • Clarify who decides on severe actions (e.g., taking services offline).

  3. Set Up Basic Monitoring and Alerts

  4. Coordinate with Third Parties

    • If you rely on external suppliers or a cloud MSP, note their support lines and escalation processes in your checklist.

  5. Review and Refine After Each Incident

    • Conduct a mini post-mortem for any downtime or breach, adding lessons learned to your ad-hoc plan.

By drafting a minimal IR checklist, assigning key roles, enabling basic alerts, and learning from each incident, you can quickly improve your readiness without a massive resource investment.

Initial Documentation at Service Launch: A documented incident response plan is required and established at the point of introducing a new service to the live environment.

How to determine if this good enough

Your organisation mandates that each new service or application must have a written incident response plan before going live. You might see it as “good enough” if:

  1. Consistent Baseline

    • All teams know they must produce at least a minimal IR plan for each service, preventing complete ad-hoc chaos.

  2. Alignment with Launch Processes

    • The IR plan is part of the “go-live” checklist, ensuring a modicum of readiness.
    • Teams consider logs, metrics, and escalation paths from the start.

  3. Improved Communication

    • Stakeholders (e.g., dev, ops, security) discuss incident preparedness prior to launch, reducing confusion later.

While requiring IR documentation at service launch is beneficial, plans can become outdated if not revisited. Also, if the IR plan remains superficial, your team may not be fully prepared for evolving threats.

How to do better

Below are rapidly actionable ways to strengthen an initial documented IR plan:

  1. Integrate IR Documentation into CI/CD

    • If you maintain an Infrastructure as Code or pipeline approach, embed references to the IR plan or scripts:
      • e.g., one-liners explaining how to isolate or roll back in the event of a security alert.

  2. Automate Some Deployment Checks

  3. Link IR Plan to Monitoring Dashboards

    • Provide direct references in the plan to the dashboards or logs used for incident detection:
      • This helps new team members quickly identify relevant data sources in a crisis.

  4. Consult Gov & NCSC Patterns

  5. Schedule a 3-Month Review Post-Launch

    • Ensure the IR plan is updated after initial real-world usage.
    • Adjust for any changes in architecture or newly discovered risks.

By embedding IR considerations into your pipeline, linking them to monitoring resources, referencing official guidance, and doing a post-launch review, you maintain an up-to-date plan that effectively handles incidents as the service evolves.

Regularly Updated Incident Plan: The incident response plan is not only documented but also periodically reviewed and updated to ensure its relevance and effectiveness.

How to determine if this good enough

Here, your organisation’s IR plan is living documentation. You might consider it “good enough” if:

  1. Periodic Reviews

    • Your security or ops teams revisit the IR plan at least quarterly or after notable incidents.
    • Updates reflect changes in architecture, threat landscape, or staff roles.

  2. Cross-Team Collaboration

    • Dev, ops, security, and possibly legal or management teams give input on the IR plan, ensuring a well-rounded approach.

  3. Moderate Testing

    • You occasionally run tabletop exercises or partial simulations to validate the plan.

Even so, you may enhance integration with broader IT continuity strategies or increase the frequency and realism of exercises. NCSC’s incident response maturity guidance typically advocates regular testing and cross-functional involvement.

How to do better

Below are rapidly actionable ways to elevate a regularly updated IR plan:

  1. Link Plan Updates to Service/Org Changes

    • If new microservices launch or staff roles shift, require an immediate plan review:
      • e.g., add or remove relevant escalation points, update monitoring references.

  2. Automate IR Plan Distribution

    • Store the IR plan in version control (like GitHub), so everyone can see changes easily:
      • e.g., label each revision with a date or release tag.
    • This fosters transparency and avoids outdated copies lurking in email threads.

  3. Encourage DR Drills

  4. Include Ransomware or DDoS Scenarios

  5. Regular Stakeholder Briefings

    • Present IR readiness status updates to leadership or departmental leads, aligning them with the IR plan improvements.

By linking plan updates to actual org changes, distributing it via version control, frequently testing via drills, and preparing for advanced threats, you maintain an agile, effective IR plan that evolves with your environment.

Integrated and Tested Plans: Incident response planning is integrated into the broader IT and business continuity planning. Regular testing of the plan is conducted to validate procedures and roles.

How to determine if this good enough

In this scenario, your incident response plan doesn’t sit in isolation— it’s part of a holistic approach to continuity, including DR (Disaster Recovery) and resilience. You might consider it “good enough” if:

  1. Seamless Coordination

    • If an incident occurs, your teams know how to escalate, who to contact in leadership, and how to pivot to DR or business continuity plans.

  2. Frequent Drills

    • You test different scenarios (network outages, data breaches, cloud region failovers) multiple times per year, refining the plan each time.

  3. Proactive Risk Management

    • The plan includes risk assessment outputs from continuity or resiliency committees, ensuring coverage of the top threats.

If you frequently test and unify IR with continuity, you likely handle incidents with minimal confusion. However, you can still refine procedures by adding ephemeral environment testing or advanced threat simulations. NCSC guidance on exercising incident response often recommends more thorough cross-team exercises.

How to do better

Below are rapidly actionable ways to further optimise integrated, tested IR plans:

  1. Adopt Multi-Cloud or Region Failover Testing

  2. Expand Real-Time Monitoring Integration

  3. Formalise Post-Incident Reviews

  4. Include Communication and PR

  5. Use NIST 800-61 or NCSC Models

    • Evaluate if your IR plan’s phases (preparation, detection, analysis, containment, eradication, recovery, post-incident) align with recognised frameworks.

By simulating cross-region failovers, integrating real-time alert triggers with continuity plans, conducting thorough post-incident reviews, and weaving communications into the IR plan, you maintain a robust, seamlessly tested approach that can respond to diverse incident scenarios.

Rehearsed and Proven Response Capability: Incident response plans are not only documented and regularly updated but also rigorously rehearsed. The organisation is capable of successfully recovering critical systems within a working day.

How to determine if this good enough

At the highest maturity level, your IR plan is thoroughly integrated, tested, and refined. You might consider it “good enough” if:

  1. Regular Full-Scale Exercises

    • You conduct realistic incident drills—maybe even involving third-party audits or multi-department collaboration.
    • Failover or system restoration is verified with near real-time performance metrics.

  2. Near-Immediate Recovery

    • Critical systems can be restored or replaced within hours, if not minutes, meeting strict RPO (Recovery Point Objective) and RTO (Recovery Time Objective) requirements.

  3. Cross-Government Readiness

    • You coordinate IR planning with other public sector bodies where interdependencies exist (e.g., healthcare, local councils).

While already impressive, continuous improvement is possible through refining automation, advanced threat hunting, or adopting chaos engineering to test response to unknown failure modes. NCSC’s advanced incident management guidelines recommend ongoing learning and adaptation.

How to do better

Even at this advanced stage, below are rapidly actionable refinements:

  1. Embed Chaos Drills

    • Randomly inject failures or security anomalies in production-like environments to ensure IR readiness:

  2. Adopt AI/ML-Driven Threat Detection

  3. Coordinate Regional or Multi-department Exercises

  4. Link IR Performance to Gov Accountability

    • Provide leadership with metrics or dashboards that show how quickly critical services can be restored.
    • This fosters ongoing support for practicing and funding IR improvements.

  5. Benchmark with International Standards

    • Assess if your IR process meets or exceeds frameworks like [NIST SP 800-61], [ISO 27035], or related global best practices.
    • Update or fine-tune accordingly.

By regularly practicing chaos drills, leveraging AI-driven threat detection, collaborating with other agencies, and aligning with recognised international standards, your IR capabilities become even more robust. This ensures you stay prepared for evolving threats while maintaining compliance and demonstrating exceptional public sector resilience.

Keep doing what you’re doing, and consider writing up your incident response practice experiences (e.g., tabletop drills, real-world successes) in a blog post or internal case studies. Submit pull requests to this guidance or public sector best-practice repositories so others can learn from your advanced approaches to incident preparedness and response.

People

How does your organisation engage with cloud providers to develop capabilities and services?

Minimal Interaction with Cloud Providers: The relationship with cloud providers is transactional, brokered through a third party, and limited to accessing their services without any significant direct contact or support from their account or technical teams.

How to determine if this good enough

Your organisation may simply use a cloud provider’s console or basic services without actively engaging them for training, account management, or technical guidance. This might be considered “good enough” if:

  1. Low Cloud Adoption

    • You only run a small set of workloads, and your staff have enough expertise to handle them without external help.

  2. Limited Requirements

    • You have no pressing need for advanced features, cost optimisation, or architectural guidance.

  3. No Advanced Security/Compliance Demands

    • Basic usage without deeper collaboration may suffice if your environment has minimal compliance or security constraints and your internal skills are adequate.

However, minimal engagement often leads to missed opportunities for cost savings, architecture improvements, or robust security best practices that a provider’s support team could offer—especially given NCSC cloud security recommendations for public sector contexts.

How to do better

Below are rapidly actionable steps to move from minimal interaction to stronger collaboration with cloud providers:

  1. Set Up Basic Account Management Contacts

  2. Use Vendor Documentation & Quickstart Guides

    • Encourage staff to leverage official tutorials and quickstarts for key services (compute, storage, networking).
    • Reference NIST Cloud Computing resources for broad conceptual best practices.

  3. Attend Vendor Webinars/Events

  4. Implement Minimal Security Best Practices

  5. Document Next Steps

    • E.g., “In 3 months, explore a higher support tier or schedule a call with a provider solutions architect to discuss cost or architecture reviews.”

By establishing basic contacts, using vendor quickstarts, tapping into free events, and implementing minimal security measures, you start reaping more value from your cloud provider relationship and set the stage for deeper engagement.

Basic Support Utilisation: Some basic support services from cloud providers are utilised, such as occasional technical assistance or access to standard documentation and resources.

How to determine if this good enough

Your organisation has begun reaching out to the cloud provider’s support channels for assistance (e.g., tickets, phone calls, or chat) on an as-needed basis. This could be “good enough” if:

  1. Occasional Issues

    • You typically resolve common problems quickly using vendor documentation, and only open support tickets for unusual or moderate complexity issues.

  2. Low Complexity or Growth

    • Your environment is stable, not requiring advanced architecture reviews or cost optimisation sessions with provider specialists.

  3. Reasonable Timely Assistance

    • The basic support meets your current operational SLA—especially if downtime or critical incidents remain infrequent.

Yet, to maximise public sector service resilience and cost efficiency, you might benefit from more proactive outreach, architecture reviews, or training options. NCSC’s operational resilience guidance often recommends deeper engagement for critical digital services.

How to do better

Below are rapidly actionable ways to evolve beyond basic support:

  1. Establish Regular Check-Ins with Account Managers

  2. Request Architecture/Cost Reviews

    • Providers typically offer free or low-cost reviews to identify cost-saving or performance improvements:
      • e.g., AWS Well-Architected Review, Azure Architecture Review, GCP Architecture Check, OCI Architecture Center.

  3. Attend or Organise Vendor-Led Training

  4. Leverage Vendor Communities & Forums

  5. Institute a “Support Triage” Process

    • Define guidelines on which issues can be solved internally vs. escalated to the provider to expedite resolution times.
    • Helps staff know when to open tickets and what info to include.

By scheduling regular check-ins with account managers, requesting architecture and cost reviews, organising training sessions, and clarifying a support triage process, you step up from reactive usage of basic support to a more proactive and beneficial relationship.

Regular Interaction and Support: There is regular interaction with cloud provider account managers, including access to standard training and support services to assist in leveraging cloud capabilities.

How to determine if this good enough

At this stage, your organisation has established a relationship with the provider’s account or technical teams, periodically engaging them for advice or standard support. You might consider it “good enough” if:

  1. Frequent Exchanges

    • Monthly or quarterly calls, email updates, or Slack channels with the provider’s team, leading to timely advice on new services.

  2. Technical Workshops

    • You’ve participated in fundamental training or architecture sessions that help refine your environment.

  3. Clear Escalation Paths

    • If major incidents occur or you need advanced cost optimisation, you know how to escalate within the provider’s organisation.

While this approach can keep your environment stable and cost-aware, you could further deepen the partnership for tailored solutions, specialised trainings, or advanced architecture reviews aligned with public sector compliance. NCSC’s supply chain guidance encourages robust vendor relationships that go beyond minimal interactions.

How to do better

Below are rapidly actionable ways to leverage regular provider interaction more effectively:

  1. Pursue Dedicated Technical Engagement

  2. Targeted Workshops for Specific Projects

  3. Co-Develop a Cloud Roadmap

    • With the provider’s account manager, outline next-year priorities: e.g., expansions to new regions, adopting serverless, or cost optimisation drives.
    • Ensure these are documented in a shared action plan.

  4. Engage in Beta/Preview Programs

    • Providers often invite customers to test new features, offering direct input.
    • This can yield early insights into tools beneficial for your departmental use cases.

  5. Share Feedback on Public Sector Needs

    • Raise local government, NHS, or departmental compliance concerns so the provider can adapt or recommend solutions (e.g., private endpoints, advanced encryption key management).

By scheduling advanced support tiers or specialised workshops, co-developing a cloud roadmap, participating in early feature programs, and continuously feeding back public sector requirements, you strengthen the partnership for mutual benefit.

Proactive Engagement and Tailored Support: The organisation engages proactively with cloud providers, receiving tailored support, training, and workshops that align with specific needs and goals.

How to determine if this good enough

In this scenario, your interactions with the provider aren’t just frequent—they’re customised for your department’s unique challenges and objectives. You might see it as “good enough” if:

  1. Joint Planning

    • Provider and internal teams hold planning sessions (quarterly or bi-annual) to match new services with your roadmap.

  2. Customised Training

    • You have in-person or virtual workshops focusing on your tech stack (e.g., AWS for HPC, Azure for AI, GCP for serverless, OCI for specialised Oracle workloads) and departmental constraints.

  3. Aligned Security & Compliance

  4. High Adoption of Best Practices

    • You regularly adopt well-architected reviews, cost optimisation sessions, or advanced managed services to streamline operations.

If your environment thrives under this proactive arrangement, you likely gain from reduced operational overhead and timely adoption of new features. Nonetheless, you can often elevate to a fully strategic partnership that involves co-marketing or advanced cloud transformation programs.

How to do better

Below are rapidly actionable ways to deepen this proactive, tailored relationship:

  1. Establish Joint Success Criteria

    • e.g., “Reduce average monthly cloud cost by 20%,” or “Achieve 99.95% uptime with no unplanned downtime over the next quarter.”
    • Collaborate with the provider’s solution architects to measure progress monthly.

  2. Conduct Regular Technical Deep-Dives

    • If using advanced analytics or HPC, schedule monthly architecture feedback with vendor specialists who can propose further optimisation or new service usage.
    • Incorporate relevant NIST SP 500-299 HPC guidelines or domain-specific standards if relevant.

  3. Engage in Co-Innovation Programs

  4. Formalise an Enhancement Request Process

    • For feature gaps or special compliance needs, let your account team log these requests, referencing [NCSC or GOV.UK requirements].
    • Potentially expedite solutions that meet public sector demand.

  5. Public Sector Showcases

    • Offer to speak at vendor events or in case studies, highlighting your success:
      • This often results in further tailored support or early access to relevant solutions.

By defining success metrics, scheduling technical deep-dives, pursuing co-innovation, and ensuring an open channel for feature requests, you make the most of your proactive provider engagement—driving continuous improvement in alignment with public sector priorities.

Strategic Partnership with Comprehensive Support: Cloud providers are engaged as strategic partners, offering comprehensive support, including regular training, workshops, and active collaboration. This partnership is instrumental in realising strategic goals and includes opportunities for the organisation to showcase its work through the provider’s platforms.

How to determine if this good enough

At this highest maturity stage, your organisation forms a deep strategic alliance with the provider, leveraging broad support and showcasing initiatives publicly. You might consider it “good enough” if:

  1. Integrated Strategic Alignment

    • You and the provider co-plan multi-year roadmaps, ensuring cloud solutions directly serve departmental missions (e.g., digital inclusion, citizen service modernisation).

  2. Extensive Training & Development

    • Your staff frequently attend advanced workshops or immersion days, possibly earning official cloud certifications.

  3. Joint Marketing or Showcasing

    • The provider invites you to speak at summits or user conferences, highlighting your innovative public sector achievements.

  4. Robust and Timely Innovation

    • You often test or adopt new services early (alpha/beta features) with the provider’s help, shaping them to UK public sector needs.

While you may already be a leader in cloud adoption, continuous adaptation to new threats, technologies, and compliance updates remains essential. NCSC’s agile resilience approach suggests regular updates and real-world exercises to preserve top-tier readiness.

How to do better

Even at this advanced level, below are rapidly actionable ways to refine a strategic partnership:

  1. Co-Develop Advanced Pilots

    • Test cutting-edge solutions, e.g., advanced AI/ML for predictive analytics, HPC for large-scale modeling:
    • This pushes your public sector services into future-forward innovations.

  2. Integrate Multi-Cloud or Hybrid Strategies

  3. Spearhead Cross-Government Collaborations

    • Collaborate with local councils, NHS, or other agencies—invite them to share your advanced partnership benefits, referencing GOV.UK’s cross-government digital approach.
    • Potentially form shared procurement or compliance frameworks with the provider’s help.

  4. Ensure Regular, Comprehensive Security Drills

    • Pair with your provider for joint incident simulations, verifying consistent coverage of best practices:

  5. Establish a Lessons Learned Repository

    • Each joint initiative or advanced workshop should produce shareable documentation or “playbooks,” continuously updating your knowledge base for broader departmental usage.

By pushing into co-developed pilots, multi-cloud or hybrid expansions, cross-government collaborations, advanced security drills, and structured knowledge sharing, you maintain a forward-looking, fully integrated partnership with your cloud provider—ensuring ongoing alignment with strategic public sector aspirations.

Keep doing what you’re doing, and consider sharing your experiences (e.g., co-pilots, advanced solutions) in blog posts or on official channels. Submit pull requests to this guidance or related best-practice repositories to help others in the UK public sector benefit from your advanced collaborations with cloud providers.

How does your organisation manage and incentivise the completion of cloud-related training and certification goals?

No Formal Training Support: There is no formal support for certification or training, nor are any specific goals or targets defined for employee development in cloud skills.

How to determine if this good enough

If your organisation has no structured approach to cloud training—leaving staff to self-educate without guidance or incentives—it might be “good enough” if:

  1. Minimal Cloud Adoption

    • Cloud usage is negligible, so advanced training isn’t yet critical to daily operations.

  2. Tight Budget or Staffing Constraints

    • Leadership is unable or unwilling to allocate resources for training, preferring ad-hoc learning.

  3. No Immediate Compliance Demands

    • You have no pressing requirement for staff to hold certifications or demonstrate skill levels in areas like security or cost optimisation.

However, ignoring staff development can lead to skill gaps, security vulnerabilities, and missed cost-saving or operational improvement opportunities. NCSC’s cloud security guidance and NIST frameworks emphasize trained personnel as a cornerstone of secure and effective cloud operations.

How to do better

Below are rapidly actionable steps to introduce at least a minimal structure for cloud-related training:

  1. Create a Basic Cloud Skills Inventory

    • Ask staff to self-report familiarity with AWS, Azure, GCP, OCI, or relevant frameworks (like DevOps, security, cost management).
    • This inventory helps identify who might need basic or advanced training.

  2. Encourage Free Vendor Resources

  3. Sponsor One-Off Training Sessions

    • If resources are extremely limited, schedule a short internal knowledge-sharing day:
      • For instance, have a staff member who learned AWS best practices do a 1-hour teach-in for colleagues.

  4. Reference GOV.UK and NCSC Guidelines

  5. Plan for Future Budget Requests

    • If adoption grows, prepare a case for funding basic training or at least paying for exam vouchers, showing potential cost or security benefits.

By initiating a simple skills inventory, directing staff to free resources, hosting internal sessions, and referencing official guidance, you plant the seeds for more structured, formalised cloud training down the line.

Managerial Discretion on Training: Training and certifications are supported at the discretion of individual managers. Team-level training goals are set but not consistently monitored or reported.

How to determine if this good enough

When some managers actively encourage or fund cloud training while others do not, you might consider it “good enough” if:

  1. Decentralised Teams

    • Each team’s manager sets development priorities, leading to variability but still some access to training budgets.

  2. Moderate Demand

    • Some staff are obtaining certifications or improved knowledge, though there’s no overarching organisational push for uniform cloud competencies.

  3. Acceptable Skills Coverage

    • You can handle day-to-day cloud tasks, with no glaring skill shortage in critical areas like security or cost optimisation.

Yet, inconsistency can result in some teams lagging behind, risking security or performance issues. NIST SP 800-53 “Personnel Security” controls and NCSC workforce security guidelines recommend more structured approaches for critical technology roles.

How to do better

Below are rapidly actionable steps to unify manager-led training into a more consistent approach:

  1. Set Organisation-Wide Cloud Skill Standards

  2. Track Training Efforts Centrally

    • Even if managers sponsor training, request monthly or quarterly updates from each manager:
      • Summaries of who took which courses, certifications earned, or next steps.

  3. Provide a Shared Training Budget or Resource Pool

    • Instead of leaving it entirely to managers, allocate a central fund for cloud courses or exam vouchers.
    • Teams can draw from it with minimal bureaucracy, ensuring equity.

  4. Host Cross-Team Training Days

    • Let managers co-sponsor internal “training day sprints,” where staff from different teams pair up for labs or workshops:
      • Possibly invite vendor solution architects for a half-day session on cost optimisation or serverless.

  5. Reference GOV.UK & NIST on Training Governance

By defining organisation-wide skill baselines, tracking training across teams, offering a shared budget, and running cross-team training events, you build a more equitable and cohesive approach—improving consistency in cloud competence.

Corporate-Level Training Support and Tracking: Training and certifications are strongly supported with allocated budgets and managerial encouragement. Team-level training goals are consistently defined, tracked, and reported at the corporate level.

How to determine if this good enough

Your organisation invests in cloud training at a corporate level, providing funds and tracking progress. You might consider it “good enough” if:

  1. Clear Funding & Targets

    • A portion of the budget is allocated for staff to attend vendor courses, exam fees, or relevant conferences.

  2. Consistency Across Departments

    • Each department sets training goals, reports progress, and aligns with overall skill objectives. This ensures no single team lags behind.

  3. Organisational Visibility

    • Leadership sees monthly/quarterly metrics on certifications achieved, courses completed, and can address shortfalls.

This robust structure fosters a learning culture, but you can refine it by tailoring training to specific roles or tasks, and by integrating self-assessment or advanced incentives. NCSC’s workforce development advice often supports role-specific skill mapping, especially around security.

How to do better

Below are rapidly actionable improvements:

  1. Customise Training by Role Path

  2. Incorporate Regular Skills Audits

    • Each quarter or half-year, staff update training statuses and new certifications.
    • Identify areas for further focus, e.g., advanced security or HPC skills.

  3. Implement Gamified Recognition

    • e.g., awarding digital badges or points for completing specific labs or passing certifications:
      • Ties in with internal comms celebrating achievements, boosting morale.

  4. Align Training with Security & Cost Goals

    • For instance, if cost optimisation is a priority, encourage staff to take relevant vendor cost management courses.
    • If advanced security is crucial, highlight vendor security specialty paths.

  5. Coordinate with GOV.UK Skills Framework

By mapping certifications to roles, regularly auditing skills, gamifying recognition, and aligning training with strategic objectives, you embed continuous cloud skill growth into your corporate culture—ensuring sustained readiness and compliance.

How to determine if this good enough

In this scenario, training is not only supported at a corporate level, but also each role has a defined skill progression, and staff regularly measure themselves. You might consider it “good enough” if:

  1. Strong Ownership of Growth

    • Employees see a clear path: e.g., from Cloud Practitioner to Solutions Architect Professional or from DevOps Associate to Security Specialist.

  2. Regular Reflection

    • Staff hold self-assessment sessions (quarterly or semi-annually) to gauge progress and plan next certifications.

  3. Alignment with Team & Organisational Goals

    • Each role’s recommended cert directly supports the team’s mission, whether optimising costs, enhancing security, or building new services.

If your approach fosters a culture of self-driven learning supported by structured role paths, it’s likely quite effective. Yet you can deepen it with formal incentives or broader organisational recognition programs.

How to do better

Below are rapidly actionable ways to refine role-based training and self-assessment:

  1. Integrate Self-Assessments into Performance Reviews

    • Encourage staff to reference role-based metrics during appraisals:
      • e.g., “Achieved AWS Solutions Architect – Associate, aiming for Azure Security Engineer next.”
    • Ties personal development to formal performance frameworks.

  2. Provide “Skill Depth” Options

    • Some staff may prefer broad multi-cloud knowledge, while others want deep specialisation in a single vendor:
      • e.g., a “multi-cloud track” vs. “AWS advanced track” approach.

  3. Enable Peer Mentoring

    • Pair junior staff who want a certain certification with an experienced internal mentor or sponsor.
    • Encourages knowledge sharing, reinforcing your training culture.

  4. Automate Role-Based Onboarding

    • New hires get automatically assigned recommended learning modules or labs:
      • e.g., AWS Qwiklabs, Azure Hands-on Labs, GCP Quick Labs, or OCI hands-on labs that match their role.

  5. Check Alignment with NCSC & NIST

By linking self-assessments to performance, diversifying skill tracks, enabling peer mentoring, and automating onboarding processes, you create a fully integrated environment where each role’s learning path is clear, self-directed, and aligned to organisational needs.

Incentivised and Assessed Training Programs: Employees completing certifications are rewarded with merit incentives and receive structured guidance and development plans. Periodic formal role-specific assessments are conducted, with achievements recognised through systems like GovUKCloudBadges.

How to determine if this good enough

At this top level, your organisation not only maps roles to training paths but also actively rewards certifications, publicises achievements, and ensures ongoing development. You might consider it “good enough” if:

  1. Formal Recognition & Incentives

    • Staff see a direct benefit (financial or career progression) upon earning relevant certs or completing advanced training.

  2. Regular Assessments

    • Beyond self-assessment, formal checks (e.g., exam simulations or performance evaluations) confirm skill proficiency.

  3. Public Acknowledgment

    • Achievements are recognised across teams or even externally (e.g., internal newsletters, [GovUKCloudBadges-like digital badges], vendor’s success stories).

  4. Continuous Evolution

    • As cloud services evolve, employees are encouraged to re-certify or pursue new advanced specialisations.

Even so, you can push further by connecting training outcomes directly to advanced strategic goals or building multi-department training programs. NCSC’s emphasis on robust workforce readiness often suggests cross-organisational knowledge sharing.

How to do better

Below are rapidly actionable suggestions to perfect an incentivised and assessed training program:

  1. Tie Certifications to Mastery Projects

    • In addition to passing exams, employees might complete real, in-house projects demonstrating they can apply those skills:
      • e.g., building a pilot serverless application or implementing end-to-end security logging using NCSC best practices.

  2. Organise Internal “Training Sprints” or Hackathons

    • e.g., a week-long challenge where staff pursue advanced certification labs together, culminating in recognition or prises.

  3. Reward Mentors

    • If staff help others achieve certifications, consider awarding them additional recognition or digital badges:
      • Encourages a culture of mentorship and upskilling.

  4. Set Up Cross-Government Partnerships

  5. Monitor ROI & Impact

    • Track how training improvements affect cost optimisation, user satisfaction, or speed of service releases:
      • Present these metrics to leadership as evidence that the incentivised approach works.

By coupling incentives with real project mastery, hosting hackathons, rewarding mentors, forming cross-government partnerships, and measuring returns, you refine a world-class training program that fosters continual cloud skill advancement and directly benefits your public sector missions.

Keep doing what you’re doing, and consider writing up your training and certification successes, possibly in blog posts or internal case studies. Submit pull requests to this guidance or other public sector best-practice repositories so fellow UK organisations can follow your lead in creating robust cloud skill-building programs.

How does your organisation prioritise cloud experience in its hiring practices of senior/executive/leadership roles, suppliers and contingent labour?

No Specific Cloud Experience Requirement: Cloud experience is not a requirement in job postings; candidates are not specifically sought out for their cloud skills.

How to determine if this good enough

Your organisation’s job postings do not mention or require cloud knowledge from applicants—even for senior/leadership roles. This could be “good enough” if:

  1. Minimal or No Cloud Usage

    • You operate almost entirely on-premises, with no plan or mandate to expand cloud operations in the near term.

  2. Highly Specialised Legacy Roles

    • Your roles focus on traditional IT (e.g., mainframe, specialised on-prem hardware), making cloud background less immediately relevant.

  3. Solely Vendor or Outsourced Cloud Expertise

    • You rely on a third-party supplier for cloud design and operations, so hiring for in-house cloud capability seems unnecessary.

However, ignoring cloud experience can become a blocker if your organisation decides to modernise or scale digital services. NCSC’s strategic cloud adoption guidance and GOV.UK’s Cloud First policy often suggest building at least some internal cloud capability to ensure secure and efficient usage.

How to do better

Below are rapidly actionable steps to begin emphasizing cloud skills in hiring:

  1. Add Cloud Awareness to Job Descriptions

  2. Encourage Current Staff to Share Cloud Knowledge

    • If you have even one or two employees with cloud expertise, host internal lunchtime talks or short workshop sessions.
    • Build a minor internal market for cloud knowledge so that future roles can specify these basic competencies.

  3. Prepare for Cloud-Focused Future

    • If you have a known modernisation program, consider building a pipeline of cloud-savvy talent:
      • Start by adding basic cloud competence to “desired” (not required) criteria in some new roles.

  4. Reference NIST & NCSC Workforce Guidance

  5. Short Internal Hackathons

    • Let staff explore a simple cloud project, e.g., deploying a test app or serverless function.
    • This stirs interest in cloud skills, naturally leading to job postings that mention them.

By introducing even minor cloud awareness requirements, providing internal knowledge sharing, referencing official frameworks, and organising small hackathons, you start shifting your hiring practices to future-proof your organisation’s cloud readiness.

Selective Requirement for Cloud Experience: Some job postings, particularly those in relevant areas, require candidates to have prior cloud experience.

How to determine if this good enough

Your organisation mentions cloud skills for roles that clearly need them (e.g., DevOps, security engineering), while other positions (senior leadership, less technical roles) remain silent on cloud. This may be “good enough” if:

  1. Targeted Cloud Adoption

    • Only certain teams or projects are using cloud extensively, so broad-based cloud requirements aren’t mandatory.

  2. Reasonable Cost/Benefit

    • The budget and number of critical cloud roles are matched, so your approach to selectively recruiting cloud talent covers current demands.

  3. Manager-Led Approach

    • Hiring managers decide which roles should involve cloud experience, ensuring teams that do need it get the right people.

While this step ensures crucial roles have the necessary cloud skills, it may cause gaps in leadership or strategic roles if they remain cloud-agnostic. GDS leadership roles often emphasize digital knowledge, so integrating cloud awareness can future-proof your organisation’s direction.

How to do better

Below are rapidly actionable improvements:

  1. Include Cloud Skills for Leadership

    • For senior or executive positions that influence technology strategy, add “awareness of cloud architectures and security” to the job description.
    • This aligns with modern public sector digital leadership standards.

  2. Establish Clear Criteria

    • Define which roles “must have,” “should have,” or “could have” cloud experience:
      • e.g., for a principal engineer or head of infrastructure, cloud experience is “must have.” For a data analyst, it might be “should have” or optional.

  3. Collaborate with HR or Recruitment

    • Ensure recruiters understand terms like “AWS Certified Solutions Architect,” “Azure DevOps Engineer Expert,” or “GCP Professional Cloud Architect.”
    • They can better filter or source candidates if they know relevant cloud certifications or skill sets.

  4. Assess Supplier Cloud Proficiency

    • When contracting or hiring contingent labor, require them to demonstrate cloud capabilities (like having staff certified to a certain level).
    • Reference NCSC supply chain security guidelines to set minimal standards for external vendors.

  5. Offer Pathways for Internal Staff

    • Provide existing employees an option to upskill into these “cloud-required” roles, reinforcing a culture of growth.
    • Supports staff retention and aligns with NIST workforce development frameworks.

By adding leadership-level cloud awareness, clarifying role-based cloud criteria, ensuring recruiters or contingent labor providers understand these requirements, and offering internal upskilling, you create a more consistent approach that meets both immediate and long-term organisational needs.

Mandatory Cloud Experience for Relevant Roles: All relevant job postings mandate cloud experience, aligning with the Digital, Data, and Technology (DDaT) role definitions.

How to determine if this good enough

Your organisation has moved to standardising cloud skill requirements in line with official frameworks, such as the GOV.UK DDaT profession capability framework. This may be “good enough” if:

  1. Clear, Public Guidance

    • Each role linked to “DDaT job family” or similar has explicit cloud knowledge expectations in the job descriptions.

  2. Established Cloud Culture

    • Colleagues in relevant fields (DevOps, architecture, security) all share a baseline of cloud competencies, ensuring consistent approaches across teams.

  3. Confidence in Ongoing Staff Development

    • You provide channels for employees to refresh or deepen their cloud skills (e.g., training budgets, exam vouchers).

If this meets your organisational scale—balancing modern service delivery with consistent cloud capabilities—it might be sufficient. Still, you can refine existing roles and adapt as the cloud environment evolves, ensuring continuous alignment with best practices from NCSC and NIST.

How to do better

Below are rapidly actionable ways to advance beyond simple mandatory requirements:

  1. Regularly Update Role Profiles

    • As AWS, Azure, GCP, and OCI evolve, review job descriptions annually:
      • e.g., adding modern DevSecOps patterns, container orchestration, serverless, or big data capabilities.

  2. Introduce Cloud Competency Levels

    • e.g., “Level 1 – Cloud Foundations,” “Level 2 – Advanced Cloud Practitioner,” “Level 3 – Cloud Architect.”
    • This ensures clarity about skill depth for each role, linking to vendor certifications.

  3. Ensure Continuity & Succession

    • Plan for staff turnover by establishing robust knowledge transfer processes, referencing NCSC workforce security advice.
    • Minimises risk if a key cloud-skilled individual leaves.

  4. Promote Multi-Cloud Awareness

    • If your organisation uses more than one provider, encourage roles to include cross-provider or “cloud-agnostic” concepts:
      • e.g., Terraform, Kubernetes, or zero-trust security patterns relevant across AWS, Azure, GCP, or OCI.

  5. Involve Senior Leadership

    • Demonstrate how mandatory cloud experience in roles directly supports mission-critical public services, cost optimisation, or security compliance, building top-level buy-in.

By routinely revising DDaT role definitions to keep pace with evolving cloud tech, defining competency levels, planning continuity, encouraging multi-cloud knowledge, and securing leadership sponsorship, you firmly embed cloud skill requirements into your organisational DNA.

Updated Role Requirements and Cloud-Focused Hiring: In addition to requiring cloud experience for new hires, existing roles have been reviewed and updated as necessary to reflect a cloud-first IT organisation.

How to determine if this good enough

Your organisation not only mandates cloud experience for new roles but also revises current positions, ensuring all necessary staff have relevant cloud responsibilities. You might see it as “good enough” if:

  1. Comprehensive Role Audit

    • You have completed an organisation-wide review of each position’s cloud skill requirements.

  2. Seamless Transition

    • Incumbent staff received training or redefined job objectives, mapping on-prem tasks to modern cloud tasks.

  3. Consistent Cloud Readiness

    • Department-wide, roles reflect a cloud-first approach—nobody is left operating purely on older skill sets if they have critical cloud duties.

Yet, as your environment or services evolve, you may consider advanced role specialisation (e.g., HPC, big data, AI/ML) or deeper multi-cloud skills. NCSC’s security frameworks might also push you to refine role-based security responsibilities.

How to do better

Below are rapidly actionable methods to keep role definitions agile in a cloud-first IT organisation:

  1. Periodically Revalidate Roles

    • Introduce a yearly review cycle where HR, IT leadership, and line managers re-check if roles align with current cloud usage or new compliance mandates (like NIST SP 800-53 revision updates).

  2. Provide Upgrade Path for Existing Staff

    • Offer training or special secondments so staff who were initially on-prem can adapt to cloud:
      • e.g., an internal “cloud transformation bootcamp,” referencing AWS, GCP, Azure, or OCI training labs.

  3. Embed Cloud in Performance Management

    • Align staff appraisal or objective-setting with adoption of new cloud skills, cost-saving initiatives, or security improvements.

  4. Create a Cloud Champion Network

    • For each department, designate “cloud champions” who ensure local roles remain updated and can escalate new skill demands if usage evolves.

  5. Follow GOV.UK or DDaT ‘Career Paths’

By systematically revalidating roles, offering staff training for on-prem to cloud transitions, linking performance metrics to cloud initiatives, and referencing official frameworks, you future-proof your team structures in a dynamic cloud landscape.

Comprehensive Cloud Experience Requirement and Role Adaptation: All job postings require cloud experience, and every existing role within the organisation has been evaluated and updated where necessary to align with the needs of a cloud-first IT organisation.

How to determine if this good enough

At this top maturity level, your organisation has fully embraced a cloud-first model: all new and existing roles incorporate cloud knowledge. You might consider it “good enough” if:

  1. Uniform Cloud Culture

    • Cloud capabilities are not a niche skill; the entire workforce, from leadership to IT specialists, understands cloud fundamentals.

  2. Frequent Revisits to Role Definitions

    • If new technologies or security best practices emerge, roles adapt quickly.

  3. Minimal Silos

    • Cross-functional collaboration is straightforward, as everyone shares a baseline cloud understanding.

  4. Strong Public Sector Alignment

Even so, continuous refinement remains important. Evolving multi-cloud strategies, advanced DevSecOps, or specialised HPC/AI solutions might require targeted skill sets.

How to do better

Below are rapidly actionable methods to keep your fully cloud-oriented workforce thriving:

  1. Nurture Advanced Specialisations

    • Some roles may deepen knowledge in containers (Kubernetes), serverless, HPC, or big data analytics:
      • e.g., adopting advanced AWS, Azure, GCP, or OCI certifications for architecture, security, or data engineering.

  2. Embed Continuous Learning

    • Offer staff consistent updates, hack days, or vendor-led labs to adapt to new features quickly:
      • e.g., monthly community-of-practice sessions to discuss the latest cloud service releases or security advisories.

  3. Encourage Cross-Organisational Collaboration

    • Collaborate with other UK public sector bodies, sharing roles or secondment opportunities for advanced cloud experiences.
    • This fosters a broader, more resilient talent pool across government.

  4. Pursue International or R&D Partnerships

    • If your department engages in cutting-edge projects or HPC research, consider co-innovation programs with cloud providers or academic institutions:
      • This might spin up entirely new specialised roles (AI/ML ops, HPC performance engineer, etc.).

  5. Benchmark Against Leading Practices

    • Leverage NCSC or NIST case studies to compare your staff skill frameworks with top-tier digital organisations.
    • Conduct periodic audits on the relevance of your role definitions and skill requirements.

By encouraging advanced specialisations, sustaining continuous learning, collaborating with other public sector entities, pursuing co-innovation partnerships, and benchmarking against top-tier best practices, you maintain an extremely robust, cloud-first workforce strategy that evolves with emerging technologies and public sector demands.

Keep doing what you’re doing, and consider writing blog posts or internal knowledge base articles about your journey toward fully integrating cloud skills into hiring. Submit pull requests to this guidance or other public sector best-practice repositories, sharing lessons learned to help others adopt a comprehensive, future-ready cloud workforce strategy.

How does your organisation qualify suppliers and partners for cloud initiatives?

Basic Qualification Based on Marketing and Framework Presence: Selection is based primarily on the supplier’s sales literature and their presence on commercial buying frameworks.

How to determine if this good enough

If your organisation’s cloud supplier or partner selection relies mostly on brochures, websites, or the fact they appear on commercial frameworks (e.g., G-Cloud, DOS), you might see it as “good enough” if:

  1. Limited Cloud Adoption

    • You procure minimal cloud services, so in-depth vetting seems excessive.

  2. Budget and Time Constraints

    • There isn’t enough capacity to run thorough due diligence or procurement evaluations.

  3. No High-Risk or Mission-Critical Projects

    • Supplier performance is not yet vital to delivering crucial citizen-facing or secure workloads.

However, relying on marketing and basic framework presence can miss critical details like deep technical expertise, security maturity, or alignment with public sector compliance requirements. NCSC supply chain guidance and NIST SP 800-161 for supply chain risk management generally recommend a more robust approach.

How to do better

Below are rapidly actionable steps to move beyond marketing-based selection:

  1. Define Basic Technical and Security Criteria

    • Before awarding a contract, ensure the supplier meets minimal security (e.g., ISO 27001) or compliance standards from NCSC’s cloud security guidelines.
    • Check if they have relevant cloud certifications (e.g., AWS or Azure partner tiers).

  2. Use Simple Supplier Questionnaires

    • Ask about their experience with public sector, references for past cloud projects, and how they manage cost optimisation or data protection.
    • This ensures more depth than marketing claims alone.

  3. Check Real-Life Feedback

    • Seek out reviews from other departments or local councils that used the same supplier:
      • e.g., informal networks, mailing lists, or digital communities of practice in the public sector.

  4. Ensure They Can Align with GOV.UK Cloud First

    • Ask if they understand government data classification, cost reporting, or typical NCSC compliance frameworks.

  5. Plan an Incremental Engagement

    • Start with a small pilot or short-term contract to validate their capabilities. If they prove reliable, expand the relationship.

By introducing a basic technical/security questionnaire, referencing real-life feedback, and piloting short engagements, you reduce reliance on marketing materials and ensure suppliers at least meet foundational public sector cloud requirements.

Initial Due Diligence and Basic Compliance Checks: Suppliers are chosen through basic due diligence, focusing on compliance with minimum standards and requirements.

How to determine if this good enough

Your organisation requires potential suppliers to pass some level of scrutiny—like verifying security certifications, relevant public sector framework compliance, or minimal references. You might consider it “good enough” if:

  1. Compliance-Heavy or Standard Services

    • The workloads require known certifications (e.g., Cyber Essentials, ISO 27001), and checking these meets your current risk appetite.

  2. Occasional Cloud Projects

    • For less frequent procurements, a standardised due diligence set (like a standard RFP template) covers enough detail.

  3. Stable Risk Profile

    • You have not encountered major incidents from suppliers, so the basic compliance approach seems adequate so far.

Still, basic checks do not confirm the supplier’s depth in technical cloud knowledge, cultural fit, or ability to handle advanced or evolving demands. NIST SP 800-161 supply chain risk management best practices and NCSC supplier assurance guidelines frequently recommend a more robust approach.

How to do better

Below are rapidly actionable methods to elevate from minimal compliance checks:

  1. Evaluate Supplier Cloud Certifications

  2. Request Past Performance or Case Studies

    • Ask for references from other UK public sector clients or comparable regulated industries.
    • Prefer those who’ve demonstrated cost-saving or security success stories.

  3. Incorporate Cloud-Specific Criteria in RFPs

  4. Conduct Briefing Sessions

    • Invite top candidates to present their capabilities or do a short proof-of-concept:
      • This highlights who truly understands your departmental needs.

  5. Ensure Contract Provisions for Exit and Risk

By integrating cloud-specific partner certifications, verifying past performance, and adding mandatory contract clauses around risk and exit, you ensure your due diligence extends beyond basic compliance to real technical and operational aptitude.

Moderate Screening for Experience and Compliance: Partners are qualified based on their industry experience, compliance with relevant standards, and basic alignment with organisational needs.

How to determine if this good enough

If your procurement team reviews suppliers by confirming they have verifiable cloud experience, meet standard public sector compliance, and fit your overarching strategic aims, you might deem it “good enough” if:

  1. Consistent Approach Across Projects

    • You use a standard set of criteria (e.g., data protection compliance, security posture, previous public sector references).

  2. Moderate Cloud Maturity

    • Your environment or projects have grown enough to demand thorough screening but not so large as to require specialised advanced partner relationships.

  3. Proven Track Record in Delivery

    • So far, these moderately screened partners have provided stable, cost-efficient solutions.

However, you might strengthen the process by including deeper due diligence around advanced areas like cost optimisation approaches, multi-cloud strategies, or specialised domain knowledge (e.g., HPC, AI) relevant to your departmental needs. NCSC’s approach to supplier assurance often encourages deeper, scenario-based evaluation.

How to do better

Below are rapidly actionable suggestions to refine moderate screening:

  1. Request a Security & Architecture ‘Show Me’ Session

    • Potential suppliers should demonstrate a typical architecture for a user story or scenario relevant to your environment:

  2. Evaluate Supplier DevSecOps Maturity

    • Ask about their CI/CD pipeline, automated testing, or DevSecOps approach:

  3. Include Cost Management Criteria

  4. Check Multi-Region or DR Capabilities

  5. Formalise Weighted Scoring

    • Allocate points for each requirement (experience, security alignment, cost management, references).
    • This ensures an objective method to compare competing suppliers.

By pushing for real demonstrations of security/architecture, assessing DevSecOps maturity, reviewing cost management solutions, checking DR abilities, and using a weighted scoring system, you gain deeper insight into a supplier’s true capability and alignment with your goals.

Comprehensive Evaluation Including Technical and Ethical Alignment: Suppliers are thoroughly vetted for technical competence, ethical alignment with organisational values, and their ability to support specific cloud objectives.

How to determine if this good enough

Here, your organisation’s procurement approach encompasses in-depth assessments—covering not only technical prowess but also cultural fit and ethical standards. You might consider it “good enough” if:

  1. Robust Vetting Process

    • You scrutinise suppliers for cloud certifications, proven track record, security compliance, sustainability practices, and ethical supply chain standards.

  2. Ethical and Green Priorities

  3. Tailored Cloud Approach

    • You ensure the supplier can deliver solutions matching your unique departmental use cases (e.g., HPC for research, serverless for citizen service web apps).

If your approach systematically ensures suppliers meet both technical and ethical standards, it likely fosters positive public sector outcomes. However, you can deepen the relationship by exploring strategic co-development or advanced partner statuses.

How to do better

Below are rapidly actionable ways to expand a comprehensive evaluation:

  1. Adopt a Custom Supplier Questionnaire

  2. Verify Internal Code of Conduct Alignment

  3. Assess Cloud Roadmap Consistency

    • Evaluate how the supplier’s technology roadmap or R&D investments align with your department’s future strategy:

  4. Engage in Pilot Co-Creation

  5. Weight Sustainability in Procurement

By employing a custom questionnaire that includes ethical, environmental, and advanced cloud criteria, verifying code-of-conduct alignment, ensuring compatibility with your technical roadmap, piloting co-creation sprints, and weighting sustainability, you further refine the comprehensive evaluation for a well-rounded supplier selection process.

Strategic Selection with Emphasis on Long-Term Value and Leadership Vision: Suppliers are selected based on a track record of excellence, recommendations from other departments, relevant certifications, demonstrable technical leadership, alignment with the civil service code, support for programs like apprenticeships, strong engagement with the leadership vision, clear articulation of risks, measurable KPIs, and long-term value for money.

How to determine if this good enough

At this highest maturity level, your selection process for cloud suppliers goes beyond technical checks—factoring in leadership alignment, risk transparency, and a future-facing approach. You might consider it “good enough” if:

  1. Holistic Procurement

    • You weigh track records, references from other government bodies, ethical stances, training or apprenticeship programs, and cost-effectiveness over time.

  2. Strong Partnership

    • The supplier aligns with your leadership’s strategic cloud vision, co-owning the roadmap for advanced digital transformation.

  3. Defined KPIs & Metrics

    • Contracts include measurable performance indicators (e.g., cost savings, user satisfaction, innovation initiatives), ensuring ongoing accountability.

  4. Security and Compliance Embedded

If you’ve reached a stage where each new supplier or partner truly integrates with your organisational goals and strategic direction, you likely ensure sustainable, high-value cloud engagements. Yet continual refinement remains essential to adapt to evolving requirements and technology.

How to do better

Below are rapidly actionable ways to enhance strategic supplier selection:

  1. Promote Multi-Year Collaboration

    • Consider multi-year roadmaps with staged deliverables and built-in agility:
      • e.g., specifying review points for adopting new cloud services or ramping up HPC/ML capabilities when needed.

  2. Publish Clear Risk Management Requirements

    • Require suppliers to maintain a living risk register, shared with your security team, covering performance, security, and cost risks.
    • Align with NCSC’s risk management approach.

  3. Encourage Apprenticeships and Community Contributions

  4. Conduct Joint Business Reviews

    • Schedule an annual or semi-annual leadership review session, focusing on:
      • Roadmap alignment, upcoming technology expansions, sustainability targets, and success stories to share cross-government.

  5. Integrate ESG and Sustainability

By defining multi-year collaborative roadmaps, embedding a shared risk register, incentivising apprenticeships or broader skill contributions, maintaining periodic leadership reviews, and factoring in sustainability metrics, you cultivate a strategic, mutually beneficial relationship with cloud suppliers. This ensures alignment with public sector values, security standards, and a visionary approach to digital transformation.

Keep doing what you’re doing, and consider writing some blog posts about your advanced supplier selection processes or opening pull requests to this guidance for others. By sharing how you integrate technical, ethical, and sustainability factors, you help other UK public sector organisations adopt strategic, future-focused cloud supplier qualification processes.

How does your organisation support and develop individuals with limited or no cloud experience for roles in cloud initiatives?

No Specific Development Path: There is no special accommodation or development path for individuals with limited or no cloud experience.

How to determine if this good enough

Your organisation may not offer any structured way for employees to learn cloud technologies. You might consider it “good enough” if:

  1. Minimal Cloud Footprint

    • Your cloud usage is extremely limited, so extensive skill-building programs seem unnecessary.

  2. No Immediate Skill Gaps

    • Current projects do not require additional cloud expertise, and operational requirements are met without training investments.

  3. Short-Term Budget or Resource Constraints

    • Funding or leadership support for formal cloud training is unavailable at present.

However, a complete lack of development opportunities can lead to skill shortages if your cloud usage suddenly expands, or if staff who do have cloud expertise leave. NCSC’s workforce security guidance and NIST workforce frameworks often emphasize proactive skill-building to maintain operational security and resilience.

How to do better

Below are rapidly actionable ways to establish a baseline development path for new cloud learners:

  1. Create a Simple Cloud Familiarisation Resource

  2. Encourage Self-Study

    • Offer small incentives (e.g., internal recognition or minor expense coverage) if employees complete a fundamental cloud course.
    • Even a simple certificate of completion fosters motivation.

  3. Promote Internal Shadowing

    • If you have at least one cloud-savvy colleague, arrange informal shadowing or pair sessions.
    • This ensures staff with zero cloud background get exposure to real tasks.

  4. Reference GOV.UK and NCSC

  5. Pilot a Tiny Cloud Project

    • If budget or time is tight, propose a small, non-critical cloud POC. Staff with no cloud experience can attempt deploying a simple website or serverless function, building basic confidence.

By assembling free training resources, sponsoring small incentives, and facilitating internal shadowing or mini pilots, you kickstart a foundational path for employees to begin acquiring cloud knowledge in a low-cost, organic way.

How to determine if this good enough

You may have a modest training approach, usually overseen by a line manager or a more experienced colleague. This can be “good enough” if:

  1. Gradual Cloud Adoption

    • The environment is evolving slowly, so incremental on-the-job training meets the immediate need.

  2. In-House Mentors

    • If there are enough knowledgeable staff who can guide newcomers on day-to-day tasks without overloading or risking burnout.

  3. Basic Organisational Support

    • A policy exists allowing some time for new staff to learn cloud basics, but no formal structured training plan is in place.

While more robust than having no path, purely on-the-job learning can be inconsistent. Some staff might receive thorough guidance, while others do not, depending on who they pair with. A standardised approach can yield faster, more uniform results—aligned with NCSC’s emphasis on skill-building for secure cloud operations.

How to do better

Below are rapidly actionable ways to strengthen basic on-the-job cloud training:

  1. Define Simple Mentorship Guidelines

    • Even if informally, specify a mentor’s role—e.g., conducting weekly check-ins, demonstrating best practices for provisioning, cost management, or security scanning.

  2. Adopt a Buddy System for Cloud Tasks

    • Pair a novice with a more experienced engineer on actual cloud tickets or incidents:
    • Encourages learning through real-world problem-solving.

  3. Introduce a Lightweight Skills Matrix

    • Track essential cloud tasks (e.g., spinning up a VM, setting up logging, basic security config) and check them off as novices learn:
      • e.g., [AWS/Azure/GCP/OCI basics], referencing relevant vendor quickstarts.

  4. Encourage Self-Paced Online Labs

    • Provide access to some structured labs:
      • [AWS Hands-on labs, Azure Lab Services, GCP codelabs, or OCI labs], guiding novices step-by-step.

  5. Celebrate Progress

    • Recognise or reward staff who complete key tasks or mini-certs (like AWS Cloud Practitioner):
      • This fosters a positive culture around skill growth.

By structuring mentorship roles, ensuring novices participate in real tasks, tracking essential skills, adding lab-based self-study, and giving recognition, you can rapidly accelerate staff readiness and consistency in cloud ops.

Structured Training and Mentorship Programs: The organisation offers structured training programs, including mentorship and peer learning, to develop cloud skills among employees with limited cloud experience.

How to determine if this good enough

Here, your organisation invests in formal training paths or bootcamps, plus assigned mentors or peer learning groups. You might consider it “good enough” if:

  1. Standardised Curriculum

    • All new cloud-related hires or existing staff can follow a consistent set of modules or labs for fundamental cloud tasks.

  2. Clear Mentorship Framework

    • Each junior or novice staff is paired with a specific mentor who checks in regularly, possibly with set learning milestones.

  3. Frequent Feedback and Peer Exchange

    • Staff share experiences in group sessions or Slack channels dedicated to troubleshooting and tips.

If such structured programs yield consistent, secure, and cost-effective cloud practices, it meets many public sector skill-building needs. Yet you can incorporate further advanced features—like external certification readiness or specialised domain training (e.g., HPC, AI). NCSC’s workforce security improvement guidelines often advocate deeper, continuous training expansions.

How to do better

Below are rapidly actionable ways to enhance structured training/mentorship:

  1. Formalise Cloud Learning Journeys

    • e.g., for a DevOps role, define stepping stones from fundamental vendor certs to advanced specialisations:
      • AWS Solutions Architect -> SysOps -> Security, Azure Administrator -> DevOps Engineer, GCP Associate Engineer -> Professional Architect, etc.

  2. Adopt Official Vendor Training Programs

  3. Establish Time Allocations

    • Guarantee staff a certain number of hours per month for cloud labs, workshops, or self-paced learning:
      • Minimises conflicts with daily duties.

  4. Integrate Real Projects into Training

    • Let trainees apply new skills to an actual low-risk project, e.g., a new serverless prototype or a cost optimisation analysis:
      • Encourages practical retention.

  5. Track & Reward Milestones

    • Summarise achievements in quarterly stats: “Team X gained five new AWS Solutions Architect Associates.”
    • Offer small recognition or career advancement alignment with Civil Service success profiles.

By defining clear cloud learning journeys, leveraging vendor training, scheduling dedicated study time, embedding real projects in the curriculum, and publicly recognising accomplishments, you foster a thriving environment for upskilling staff in cloud technologies.

Integrated Learning and Development Initiatives: Comprehensive learning initiatives, such as in-house training courses or collaborations with external training providers, are in place to up-skill employees in cloud technologies.

How to determine if this good enough

Your organisation provides robust training—like in-house cloud courses, external bootcamps, or vendor collaborations (AWS, Azure, GCP, OCI). You might consider it “good enough” if:

  1. Managed End-to-End

    • Employees sign up for consistent programs, from beginner to advanced, with recognised certification paths.

  2. Frequent Engagement

    • Regular classes or workshops ensure continuous skill growth, not just a one-time orientation.

  3. Positive Impact

    • Observed improvements in staff morale, faster cloud project delivery, and fewer errors or security incidents.

This approach likely meets most skill-building needs. Nonetheless, you can push for advanced or specialised tracks (e.g., HPC, AI/ML, security) or adopt apprenticeship or “bootcamp + aftercare” models. GOV.UK or GDS Academy courses may also be integrated to reinforce public sector-specific skill sets.

How to do better

Below are rapidly actionable tips to refine integrated learning and development:

  1. Formal Apprenticeship or Bootcamp

    • Partner with recognised training providers:
      • e.g., AWS re/Start, Azure Academy, GCP JumpStart, or Oracle Next Education for more in-depth coverage.
    • Ensure alignment with NCSC or NIST cybersecurity modules.

  2. Set Clear Learning Roadmaps by Function

    • For Dev, Ops, Security, Data roles—each has curated course combos, from fundamentals to specialised advanced topics:
      • This fosters structured progression.

  3. Involve Senior Leadership Support

    • Encourage exec sponsors to highlight success stories, attend final presentations of training cohorts, or discuss how these new skills align with departmental digital transformation goals.

  4. Combine Internal & External Teaching

    • Use a mix of vendor trainers, in-house subject matter experts, and third-party specialists for well-rounded instruction.
    • This ensures staff see multiple perspectives.

  5. Measure ROI

    • Track cost savings, decreased deployment times, or increased user satisfaction from cloud projects led by newly trained staff:
      • Present these metrics in leadership reviews, justifying ongoing investment.

By implementing apprenticeship or structured bootcamp approaches, organising role-specific learning paths, ensuring leadership buy-in, blending internal and external expertise, and measuring ROI, you develop a truly comprehensive and outcome-driven cloud skill development program.

Mature Apprenticeship/Bootcamp Program with Aftercare: A robust apprenticeship, bootcamp, or career change program exists for rapid skill development in cloud technologies. This program includes significant aftercare support to ensure long-term development and retention of the investment in these individuals.

How to determine if this good enough

At the highest level, your organisation runs a fully-fledged apprenticeship or bootcamp approach to converting staff with little-to-no cloud background into proficient cloud practitioners—backed by ongoing mentorship. You might see it “good enough” if:

  1. High Conversion Rates

    • Most participants complete the program and effectively fill cloud roles.

  2. Post-Program Support

    • After finishing, participants continue to receive coaching, refreshers, or advanced modules so their skills remain current.

  3. Strategic Workforce Planning

    • This pipeline of new cloud talent meets growing departmental or cross-government demands, minimising reliance on external hires.

Even so, continuous improvement can come through specialised advanced tracks, collaborating with other agencies on multi-disciplinary programs, or adding recognised certifications. NCSC guidance on building a secure workforce and NIST NICE frameworks reinforce deep, ongoing skill progression.

How to do better

Below are rapidly actionable ways to further refine your mature apprenticeship or bootcamp program:

  1. Expand Specialist Tracks

    • Develop advanced sub-tracks (e.g., HPC, AI/ML, Zero-Trust Security) for participants who excel at foundational cloud skills:
      • Align with vendor specialised training or NCSC/NIST security standards for deeper expertise.

  2. Coordinate Multi-department Bootcamps

    • Collaborate with local councils, NHS, or other government bodies to form a larger talent pool:
      • Shared labs, cross-government hackathons, or combined funding can scale impact.

  3. Ensure Continuous Performance Assessments

    • Conduct formal evaluations 6, 12, or 18 months post-bootcamp:
      • Checking advanced skill adoption, real project outcomes, and personal career growth.

  4. Public Acknowledgment & Advancement

  5. Incorporate Cost-Savings and ROI Proof

    • Track how newly trained staff reduce external consultancy reliance, deliver projects faster, or improve security.
    • Present data to leadership, ensuring sustained or increased budgets for these programs.

By launching specialised advanced tracks, fostering cross-department collaborations, performing ongoing performance assessments, integrating real career incentives, and measuring ROI, you secure a pipeline of skilled cloud professionals well-suited to public sector demands, maintaining a resilient workforce aligned with national digital transformation objectives.

Keep doing what you’re doing, and consider documenting your apprenticeship or bootcamp approaches in internal blog posts or knowledge bases. Submit pull requests to this guidance or other best-practice repositories so fellow UK public sector organisations can replicate your success in rapidly upskilling staff for cloud roles.

To what extent are third parties involved in the development and support of your organisation's cloud initiatives?

Complete Reliance on Third Parties: Third parties are fully responsible for all cloud work, with unrestricted access to the entire cloud infrastructure.

How to determine if this good enough

Your organisation might rely entirely on external suppliers or integrators to handle every aspect of your cloud environment (deployment, operations, security, cost optimisation). You may see this “good enough” if:

  1. Minimal Internal Capability or Resource

    • Your team lacks capacity or skills to manage cloud tasks in-house, so outsourcing everything seems more efficient.

  2. Stable, Low-Risk Environments

    • You have not encountered major issues or compliance demands; the environment is small enough that handing all access to a trusted third party is acceptable.

  3. Rigid Budget Constraints

    • Management prefers paying a single supplier cost rather than investing in building in-house skills or a DevOps team.

However, complete third-party control often creates risk if the supplier fails, is compromised, or does not align with NCSC best practices on supply chain security. Also, NIST SP 800-161 supply chain risk management advises caution in giving total external control over strategic assets.

How to do better

Below are rapidly actionable ways to reduce over-dependence on a single third party:

  1. Retain Critical Access

  2. Require Transparent Documentation

    • Request the third party produce architecture diagrams, runbooks, and logs:
      • So your internal teams can reference them and step in if needed.

  3. Set Clear SLAs and Security Requirements

  4. Conduct Periodic Access Reviews

    • Evaluate who has root-level or full access privileges. Revoke or reduce if not absolutely necessary:
      • Minimises the impact if the supplier or a contractor is compromised.

  5. Begin In-House Skill Development

By retaining critical admin access, demanding thorough documentation, setting rigorous SLAs, auditing access, and growing your internal skill base, you hedge against supplier lock-in or failure and maintain some sovereignty over crucial cloud operations.

Significant Third-Party Involvement: Third parties play a major role in delivering certain aspects of cloud work and have full access to cloud accounts.

How to determine if this good enough

If your organisation still grants external partners or suppliers broad control of cloud resources, but you handle some tasks in-house, you might deem it acceptable if:

  1. Shared Responsibilities

    • Your staff can manage day-to-day tasks while suppliers handle complex architecture, major updates, or advanced security.

  2. Periodic Oversight

    • You monitor or audit the supplier’s activity at intervals, ensuring alignment with departmental standards.

  3. Reasonable Security and Compliance

However, full account-level access can still introduce risk—particularly around misconfigurations, cost overruns, or insufficient security hardening if not carefully supervised. Evolving your posture can ensure robust, granular control.

How to do better

Below are rapidly actionable improvements:

  1. Use Granular IAM Permissions

  2. Create Supplier-Specific Accounts or Subscriptions

    • Segment your cloud environment so suppliers only see or modify what’s relevant:
      • This helps contain damage if credentials leak or get misused.

  3. Mandate Activity Logging & Auditing

    • Configure [AWS CloudTrail, Azure Monitor, GCP Cloud Logging, OCI Audit] to track every privileged action:
      • Helps detect anomalies or investigate incidents quickly.

  4. Conduct Scheduled Joint Reviews

    • Align on cost management, architecture updates, security posture with the supplier monthly or quarterly:
      • e.g., use [AWS Trusted Advisor / Azure Advisor / GCP Recommender / OCI Advisor] to see if best practices are followed.

  5. Plan for Possible Transition

    • If you decide to reduce the supplier’s role in the future, ensure documentation or staff knowledge exist to avoid single-point dependencies.

By applying least privilege IAM, isolating supplier access, logging all privileged actions, collaborating on architecture/cost reviews, and planning for possible transitions, you maintain high security while leveraging external expertise effectively.

Specialised Third-Party Support with Limited Access: Third-party providers contribute specialised knowledge and maintain ‘break glass’ (emergency) admin access only.

How to determine if this good enough

Here, your organisation typically handles daily operations, but calls on external experts for advanced tasks or emergencies—granting them only minimal privileged credentials. You might see it as “good enough” if:

  1. Mature Internal Team

    • Your staff can handle common issues; third parties fill skill gaps in HPC, ML, or specialised security incidents.

  2. Controlled Access

    • The supplier can escalate to “admin” only under defined protocols (e.g., break-glass accounts), reducing continuous broad privileges.

  3. Balanced Costs

    • You avoid paying for full outsourcing; instead, pay for specialised or on-demand engagements.

This approach offers strong security control while ensuring advanced expertise is available if required. [NCSC’s principle of “least privilege” and “need-to-know” aligns with limiting third-party access in normal operations. NIST SP 800-161 supply chain risk guidance similarly endorses restricting vendor privileges.

How to do better

Below are rapidly actionable ways to refine specialised third-party support:

  1. Automate Break-Glass Processes

    • e.g., storing break-glass credentials in a secure vault (like [AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, OCI Vault]) requiring multi-party approval or temporary permission escalation.

  2. Develop Clear Incident Protocols

  3. Perform Yearly Access Drills

    • Simulate a scenario requiring supplier intervention:
      • Validate that the break-glass account retrieval process, notifications, and post-incident re-lock steps all work smoothly.

  4. Enforce Accountability

  5. Periodic Skills Transfer

    • Let external experts run short workshops, training sessions, or knowledge transfers:
      • e.g., HPC performance tuning, advanced DevSecOps, or AI/ML best practices—improving your team’s ability to handle issues without always relying on break-glass.

By automating break-glass credentials, establishing clear incident protocols, conducting annual drills, logging all privileged actions, and regularly upskilling staff with supplier-led sessions, you can maintain strong security while accessing specialised expertise only when needed.

Specialised Knowledge without Privileged Access: Third parties provide specialised expertise but do not have any form of privileged access to cloud infrastructure.

How to determine if this good enough

Your organisation fully manages its cloud environment, relying on external experts for design reviews, architecture guidance, or training—but without granting them direct infrastructure permissions. This might be “good enough” if:

  1. Sufficient In-House Ops and Security

    • You have a capable ops and security team able to implement supplier recommendations without handing over admin keys.

  2. Low Risk of Supply Chain Compromise

    • Restricting external access to “view-only” or no direct access ensures minimal risk of unauthorised actions by a third party.

  3. Strong Cultural Collaboration

    • Communication flows well; suppliers can guide your staff effectively on advanced topics.

However, if you need external support for certain operational tasks, not giving them any direct access could slow response times or hamper complex troubleshooting. NCSC’s supply chain security advice advocates balancing minimal necessary access with real-world support requirements.

How to do better

Below are rapidly actionable ways to leverage specialised knowledge further:

  1. Add Read-Only or Auditor Roles

  2. Enable Collaborative Architecture Reviews

    • Provide sanitised environment data or architecture diagrams for the supplier to review:
      • e.g., removing any sensitive info but enough detail to yield beneficial recommendations.

  3. Request Proactive Security or Cost Analysis

  4. Formalise Knowledge Transfer

    • For each engagement, define deliverables like architectural guidelines, best-practice documents, or mini-lab sessions with staff.
    • Ensures that specialised advice becomes actionable in-house expertise.

  5. Regular Check-Ins and Feedback Loop

By granting read-only roles for better collaboration, scheduling architecture or security reviews, requesting continuous cost/security analysis, and structuring knowledge transfers, you maximise the benefits of external specialists while maintaining tight control over your environment.

Minimal or Augmentative Third-Party Role: Third parties are either not used at all or serve purely as staff augmentation, without any privileged access or holding exclusive knowledge.

How to determine if this good enough

At this highest maturity level, your organisation has robust internal cloud teams, perhaps occasionally hiring contract staff or specialised freelancers to augment efforts—but with no exclusive control or privileged role. You might consider it “good enough” if:

  1. Self-Sufficient Internal Capability

    • Your workforce covers all major cloud operations (DevOps, security, architecture, cost optimisation), reducing dependence on external vendors.

  2. Minimal or Temporary Outsourcing

    • External help is short-term, under strict direction, and does not lead or own critical processes.

  3. Complete Knowledge Ownership

    • No vendor or contractor has unique knowledge. All runbooks, configurations, or code remain well documented in-house.

If your internal team effectively manages all cloud tasks, external specialists only add temporary capacity. However, if new advanced needs arise (e.g., HPC, AI, specialised security audits), you might reintroduce deeper third-party involvement—so readiness for that possibility is key.

How to do better

Below are rapidly actionable ways to refine a minimal/augmentative third-party approach:

  1. Maintain Partnerships Without Access

  2. Ensure Proper Documentation and Knowledge Transfer

    • Whenever you briefly hire contingent staff, they must update runbooks, diagrams, or code repos:
      • Mitigates risk of “knowledge walkout.”

  3. Incorporate Cross-Government Collaboration

    • For advanced or new cloud initiatives, consider partnering with other public sector bodies first, exchanging staff or expertise:
      • e.g., short secondments or co-located sprints can accelerate learning while minimising external costs.

  4. Benchmark Internal Teams Regularly

  5. Public Sector Thought Leadership

    • If you have minimal external dependencies, you likely have strong internal mastery—consider sharing success stories or best practices across local councils or GOV.UK communities of practice.

By maintaining a supplier list without granting them privileged access, enforcing thorough knowledge transfer, collaborating cross-government for specialised expertise, continuously benchmarking in-house capabilities, and showcasing your self-reliant approach, you preserve a high level of operational independence aligned with secure, cost-effective public sector cloud usage.

Keep doing what you’re doing, and consider writing about your strategies for third-party involvement in cloud initiatives or creating pull requests to this guidance. This helps other UK public sector organisations learn how to balance external expertise with robust internal control over their cloud environment.

What are the success criteria for your cloud team?

No Defined Success Criteria: The cloud team operates without specific, defined criteria for measuring success.

How to determine if this good enough

Your cloud team lacks explicit metrics, goals, or success factors to gauge progress. This can feel acceptable if:

  1. Minimal Cloud Footprint

    • The team is in an exploratory or very early stage, with limited resources.
    • There’s no immediate pressure to produce measurable outcomes.

  2. Short-Term or Experimental Cloud Efforts

    • The team is focusing on small PoCs without a formal success framework.

  3. Uncertain Organisational Direction

    • Senior management hasn’t outlined a precise cloud strategy, so the team lacks guidance on what “success” means.

However, without defined criteria, it’s difficult to justify budgets, measure progress, or ensure your efforts meet public sector demands. NCSC’s cloud security best practices and GOV.UK’s technology code of practice emphasize measurable outcomes for transparency and accountability.

How to do better

Below are rapidly actionable steps to establish at least minimal success criteria:

  1. Identify Key Cloud Objectives

    • E.g., reduce hosting costs by 10%, or migrate a pilot workload to AWS/Azure/GCP/OCI.
    • Reference departmental priorities or NIST cloud computing frameworks for initial guidance.

  2. Define Simple Metrics

    • Examples: “Number of staff trained on fundamental cloud skills,” “Mean time to deploy a new environment,” “Basic cost usage reduction from month to month.”

  3. Align with Leadership

    • Present a short list of proposed success metrics to senior management for sign-off, ensuring these metrics reflect organisational or GOV.UK Cloud First policies.

  4. Track Progress Visibly

    • Use a shared dashboard or simple spreadsheet to record outcomes:
      • e.g., new workloads migrated, number of test passes, or cost changes.

  5. Create a Baseline

    • If you have no prior data, quickly measure current on-prem costs or the time it takes to provision infrastructure:
      • This baseline will contextualise progress in adopting cloud solutions.

By identifying basic cloud objectives, selecting simple metrics, confirming leadership support, tracking progress, and establishing a baseline, you move from undefined success to a workable system that can be refined as your team matures.

Initial Achievements with Proofs of Concept: Success is measured by completing initial proofs of concept or developing a ‘minimum viable cloud/platform’.

How to determine if this good enough

Your cloud team measures success by delivering small PoCs—like a pilot application running in the cloud or a “minimum viable” platform—for demonstration. This may be “good enough” if:

  1. Early Adoption Phase

    • You’re focusing on demonstrating feasibility and building internal confidence in cloud approaches.

  2. Positive Reception

    • Stakeholders are satisfied with these pilot results, seeing the potential for cost savings or faster deployments.

  3. Limited Scale

    • Organisationally, large-scale cloud migrations or complex workloads aren’t yet on the horison.

Though better than having no success criteria, limiting measurements to “PoCs delivered” can hamper progression to full production readiness. NCSC operational resilience and NIST risk management frameworks often encourage planning for broader usage once pilot success is proven.

How to do better

Below are rapidly actionable steps to advance beyond PoC-based success:

  1. Set PoC Transition Targets

    • Define a timeline or conditions under which successful PoCs move into pilot production or scale to more workloads:
      • e.g., “If the PoC meets X performance criteria at Y cost, proceed to production by date Z.”

  2. Establish Operational Metrics

  3. Involve Real End Users

    • If feasible, let a pilot serve actual staff or a subset of public users:
      • Gains more meaningful feedback on feasibility or user experience.

  4. Document & Share Learnings

  5. Link PoCs to Organisational Goals

    • Ensure each PoC addresses a genuine departmental need (like cost, user experience, or operational agility), so it’s not a siloed experiment.

By defining clear triggers for scaling PoCs, measuring advanced metrics, engaging real users, sharing lessons learned, and tying PoCs to broader goals, you accelerate from pilot outcomes to genuine organisational transformation.

Launching Workloads in Production: Success includes transitioning one or more workloads into a live production environment on the cloud.

How to determine if this good enough

In this scenario, your cloud team’s success criteria revolve around deploying real-world services or applications for actual users in cloud infrastructure. It may be “good enough” if:

  1. Demonstrable Production Usage

    • You can point to at least one or two services fully operating in the cloud, serving user or departmental needs.

  2. Basic Reliability & Cost Gains

    • Deployments show improved uptime, easier scaling, or partial cost savings over on-prem approaches.

  3. Foundation for Expansion

    • Success in these production workloads fosters confidence and sets a blueprint for migrating additional services.

Still, measuring success only by “production usage” can neglect other vital areas (like cost optimisation, security posture, or user satisfaction). NCSC’s cloud security guidance and NIST SP 800-53 controls underscore the importance of compliance, security checks, and continuous monitoring beyond just “it’s running in production.”

How to do better

Below are rapidly actionable ways to refine production-based success criteria:

  1. Track Key Operational Metrics

  2. Integrate Security & Cost Efficiency

  3. Define a Full Lifecycle Approach

    • Ensure pipelines for new features, rollbacks, or replacements are tested and documented:
      • Reduces risk of “stagnation” where workloads remain unoptimised once launched.

  4. Share Achievements & Best Practices

  5. Plan for Next Steps

    • If a single workload is successful in production, identify the next logical workload or cost-saving measure to adopt:
      • e.g., serverless expansions, HPC jobs, advanced AI/ML adoption.

By incorporating operational metrics, weaving in security and cost success factors, ensuring a continuous pipeline approach, celebrating achievements, and planning further expansions, you create a robust definition of success that fosters ongoing improvements.

Scaling Prototypes to Core Services: Success involves scaling initial prototypes to operate core technical services in the cloud, supporting business-critical applications.

How to determine if this good enough

The cloud team’s success is measured by graduating from smaller apps to significant, mission-critical systems. You might consider it “good enough” if:

  1. Mission-Critical Cloud Adoption

    • Key departmental or citizen-facing services run in the cloud, showcasing tangible operational or cost benefits.

  2. Validated Resilience & Performance

  3. Cross-Functional Buy-In

    • Architecture, finance, and security teams support your approach, indicating trust in cloud solutions for vital workloads.

However, you can refine success criteria to include advanced features like global failover, zero-downtime deployments, or integrated DevSecOps. NIST SP 800-160 systems security engineering often suggests deeper security integration once critical services are cloud-based.

How to do better

Below are rapidly actionable strategies to further scale prototypes into core services:

  1. Adopt Advanced HA/DR Strategies

  2. Integrate Automated Security Testing

  3. Quantify Impact

    • Track cost savings, performance gains, or user satisfaction improvements from scaling cloud usage.
    • Present these metrics to leadership or cross-government peers.

  4. Develop or Refine Architectural Standards

  5. Collaborate with Other Public Sector Entities

By adopting advanced resiliency and security, measuring impact thoroughly, standardising architectural approaches, and collaborating with other public sector bodies, you mature from simply scaling prototypes to robust, enterprise-level cloud service delivery.

Innovation and Value Creation Alignment: The organisation has established success criteria that not only focus on cloud-based innovation and experimentation but also on creating tangible value through transformation initiatives, all aligned with the organisation’s broader goals and strategy.

How to determine if this good enough

At this top maturity level, success measures for the cloud team emphasize innovation, experimentation, and direct ties to strategic value creation (e.g., cost savings, user satisfaction, or cross-government collaboration). You might see it “good enough” if:

  1. Clear Strategic Link

    • Each new cloud feature or pilot directly supports organisational goals (e.g., citizen service improvement, efficiency targets).

  2. Ongoing Experimentation

    • The team fosters a culture of trying new services (e.g., AI/ML, serverless, HPC), measuring success with prototypes, while being able to fail fast and learn.

  3. Demonstrable Value

    • Whether it’s improved user experience, shortened delivery cycles, or significant cost reduction, the cloud initiatives produce measurable benefits recognised by leadership.

  4. Comprehensive Security & Compliance

Even at this level, you can refine success criteria by further integrating synergy with multi-cloud or cross-department projects, shaping a broader public sector digital transformation. GOV.UK’s digital transformation agenda encourages maximising user value with minimal friction.

How to do better

Below are rapidly actionable ways to continue improving innovation- and value-centric success criteria:

  1. Adopt a Value Stream Approach

    • Link each cloud initiative to a user-facing or operational outcome:
      • e.g., reducing form-processing time from days to minutes, or improving public web performance by X%.
    • This ensures the entire pipeline, from idea to deployment, focuses on delivering measurable benefits.

  2. Incorporate Cross-Organisational Goals

    • For large departmental or multi-department programs, align success metrics to shared objectives:
      • e.g., joint cost savings, integrated citizen ID solutions, or unified data analytics capabilities.

  3. Advance Sustainability Metrics

  4. Enable Continuous Learning and Sharing

    • Promote open blog posts or internal wiki pages detailing each new experiment’s results—whether success or failure.
    • Encourages a virtuous cycle of rapid improvement.

  5. Periodically Recalibrate Metrics

    • As technology evolves, update or retire older success metrics (e.g., “time to spin up a VM” might be replaced by “time to deploy a new serverless function”), ensuring they stay relevant to strategic ambitions.

By implementing a value stream approach, embedding cross-organisational goals, focusing on sustainability, encouraging transparency in experiments, and periodically recalibrating metrics, your cloud team solidifies its role as a driver of innovation and public value creation. This ensures alignment with evolving public sector needs, best practices, and digital transformation objectives.

Keep doing what you’re doing, and consider writing blog posts about your success criteria or opening pull requests to this guidance so other public sector organisations can adopt or refine similar approaches to measuring and achieving cloud team success.

What level of executive sponsorship supports your organisation's 100% cloud adoption initiative?

No Executive Sponsorship: There is no executive support for cloud adoption, indicating a lack of strategic prioritisation at the leadership level.

How to determine if this good enough

Your initiative to adopt 100% cloud is effectively grassroots-driven, without support from executive-level leaders (CEO, CFO, CIO, or equivalent). It might be “good enough” if:

  1. Minimal Cloud Usage

    • The organisation is still in a very early exploration stage, so top leadership’s involvement appears non-essential.

  2. Limited or No Critical Workloads

    • Cloud adoption does not yet impact vital citizen services or departmental mandates, so leadership sees no urgency.

  3. No Current Funding/Resourcing Requirements

    • The teams can sustain small pilot efforts within existing budgets or staff capacity without requiring strategic direction.

However, lacking executive buy-in often results in stalled progress, inability to scale secure cloud usage, and missed opportunities for cost optimisation or digital transformation. NCSC’s cloud security guidance and GOV.UK Cloud First policy typically advise leadership alignment to ensure secure, efficient, and future-proof adoption.

How to do better

Below are rapidly actionable suggestions to secure at least minimal executive sponsorship:

  1. Document Quick-Win Success Stories

    • Show leadership how small pilots delivered cost savings, performance gains, or alignment with departmental digital goals.
    • For instance, highlight a pilot serverless function that replaced an aging on-prem script.

  2. Link Cloud Adoption to Organisational Mandates

  3. Prepare a Simple Business Case

  4. Request a Brief Meeting with a Senior Sponsor

    • Secure 15-30 minutes to share pilot results or near-term opportunities:
      • Stress risk of continuing without guidance from top leadership (e.g., security gaps, budget overruns, or duplication).

  5. Offer an Executive-Level Intro

    • Propose an hour-long cloud fundamentals overview for interested executives, possibly with vendor partner support or free training sessions.

By compiling quick-win stories, framing cloud adoption in organisational mandates, presenting a succinct business case, requesting a short meeting, and offering an executive primer, you begin building the case for at least baseline senior buy-in.

Senior Management Sponsorship: The initiative is sponsored by senior management, indicating some level of support but potentially lacking full executive influence.

How to determine if this good enough

You have some backing from directors or departmental heads (below C-level) who champion the cloud initiative. This can be “good enough” if:

  1. Visible Progress

    • The department can proceed with cloud transformations in everyday operations.
    • Key middle-management fosters departmental collaboration.

  2. Partial Funding

    • Senior managers can authorise training or pilot spending, but might need higher sign-off for large-scale expansions.

  3. Some Accountability

    • Senior managers track progress, but significant strategic shifts remain out of scope because top execs are not fully engaged.

Though beneficial, lacking the highest-level sponsorship might hinder cross-department alignment or hamper big-ticket modernisation. NCSC’s supply chain and cloud security frameworks often call for robust leadership direction for consistent security across the organisation.

How to do better

Below are rapidly actionable steps to expand from senior management to full executive endorsement:

  1. Demonstrate Departmental Wins

    • Have senior managers publicise successful departmental cloud outcomes to executives:
      • e.g., a 20% cost reduction or improved user satisfaction in a pilot citizen-facing service.

  2. Facilitate an Exec-Level Briefing

  3. Align with Organisational Strategy

  4. Request Executive Sponsor for Large-Scale Migrations

    • If you plan a major migration (like HPC, AI/ML, or large data center closure), propose a “sponsor” role for a top exec:
      • Encourages them to champion budget allocations and remove cross-department barriers.

  5. Create a Vision Statement

    • Collaborate with senior managers to draft a concise “cloud vision” for the next 1-3 years, referencing success metrics (cost, security posture, user satisfaction) to interest executives.

By showcasing departmental successes, hosting briefings with executives, integrating the initiative into overarching strategies, seeking an executive sponsor for large projects, and formalising a short vision statement, you steadily shift from partial senior sponsorship to broader top-level leadership buy-in.

C-Level Executive Sponsorship: One or more C-level executives sponsor the cloud adoption, demonstrating significant commitment at the highest levels of leadership.

How to determine if this good enough

Your cloud initiative is backed by a C-level executive (CIO, CTO, CFO, or equivalent), signaling strong leadership emphasis. It might be “good enough” if:

  1. Robust Funding & Priority

    • The sponsor secures budgets, champions cloud at board meetings, ensuring departmental alignment.

  2. Influence Across Departments

    • Cross-functional teams or other directors respect the executive’s authority, facilitating faster decisions.

  3. Tangible Results

    • With high-level backing, the cloud initiative can accelerate modernisation, cost savings, or improved service delivery.

Still, to sustain this advantage, you can adopt a structured roadmap, define deeper cultural changes, or integrate advanced DevSecOps. GOV.UK’s approach to agile/digital transformation guidance and NCSC well-architected security best practices can guide deeper integration.

How to do better

Below are rapidly actionable ways to leverage C-level sponsorship further:

  1. Develop a Multi-Year Cloud Roadmap

    • Collaborate with the C-level sponsor to define short, medium, and long-term goals:
      • e.g., incremental migrations, security enhancements, cost optimisation targets.

  2. Establish Clear KPIs & Milestones

  3. Ensure Inter-Departmental Collaboration

  4. Embed Security as a First-Class Concern

  5. Highlight Public Sector Success

    • Encourage your sponsor to share wins at internal leadership summits or cross-gov conferences, fostering further executive-level peer collaboration.

By crafting a multi-year roadmap, specifying meaningful KPIs, promoting cross-department synergy, embedding robust security from the start, and publicising achievements, you realise the full benefits of C-level sponsorship—driving cohesive, secure, and strategic cloud adoption.

Comprehensive C-Level Sponsorship with Roadmap: Full sponsorship from C-level executives, accompanied by a shared, strategic roadmap for cloud adoption and migration.

How to determine if this good enough

Here, your cloud initiative enjoys comprehensive executive support, with a well-defined plan across multiple departments or services. You might consider it “good enough” if:

  1. Clear Multi-Department Involvement

    • The entire leadership team endorses a unified cloud strategy, establishing integrated goals.

  2. Detailed Migration & Transformation Plan

    • A collaborative roadmap outlines which apps or services move first, timelines for HPC or AI expansions, or how to integrate new DevOps pipelines.

  3. Measured Organisational Impact

    • You can show cost savings, improved reliability, or user satisfaction correlating with the roadmap’s progress.

Though advanced, you can refine metrics, extend advanced HPC/AI usage, or further embed a “cloud-first” ethos across every level of staff. NCSC’s “cloud first” security posture advice and GOV.UK digital transformation frameworks remain relevant for continuous improvement.

How to do better

Below are rapidly actionable ways to strengthen a comprehensive C-level sponsorship with a strategic roadmap:

  1. Involve Staff in Roadmap Updates

    • Host quarterly open sessions where devs, ops, or security can give feedback on the strategic plan:
      • Encourages buy-in and surfaces practical constraints.

  2. Institute a Cloud Steering Committee

    • Form a cross-functional group with representation from finance, HR, security, architecture, and user departments:
      • They meet regularly to track progress, share challenges, and drive adjustments in the roadmap.

  3. Focus on Advanced Migrations or Services

  4. Integrate Multi-Cloud or Hybrid Considerations

  5. Publish Success Metrics

    • Show top-level achievements or cost savings in staff newsletters or a leadership dashboard:
      • Reinforces organisational momentum for the roadmap.

By updating the roadmap collaboratively, establishing a cloud steering committee, venturing into advanced HPC/AI/ML, acknowledging multi-cloud/hybrid scenarios, and publicising success metrics, you deepen the synergy and accountability behind your cloud adoption plan—leading to dynamic, well-supported progress.

C-Level Sponsorship Driving Cloud-First Culture: Comprehensive C-level sponsorship not only provides strategic direction but also actively fosters a culture of cloud-first adoption, experimentation, and innovation throughout the organisation.

How to determine if this good enough

At this ultimate stage, your organisation’s top leadership proactively cultivates a “cloud-first” mindset, championing experimentation and innovation. You might consider it “good enough” if:

  1. Embedded Cloud Thinking

    • Staff across all levels default to considering cloud solutions first for new projects, referencing GOV.UK Cloud First policy.

  2. High Experimentation & Safe Fail

    • DevSecOps teams conduct frequent PoCs, quickly pivoting from unsuccessful trials with minimal friction or blame.

  3. Relentless Focus on Value & Security

  4. Confidence and Autonomy

    • Teams can easily spin up new resources or adopt new services within guardrails—thanks to strong governance, automated compliance checks, and constant exec support.

Though already advanced, you can still refine cross-department synergy, adopt emerging HPC/AI capabilities, or serve as a best-practice model for other public sector organisations. Continuous improvement aligns with NIST cybersecurity frameworks and frequent updates to NCSC secure cloud guidelines.

How to do better

Below are rapidly actionable ways to continuously strengthen a cloud-first culture under comprehensive C-level sponsorship:

  1. Scale Innovation Hubs

    • If you have a center of excellence or an innovation lab, extend its scope to HPC, AI/ML, IoT, or advanced HPC:
      • e.g., adopt HPC solutions from AWS, Azure, GCP, OCI, incorporating domain specialists.

  2. Open Source & Share

    • Encourage teams to open-source relevant code or automation, participating in cross-government communities:

  3. Enable Real-Time Security & Compliance

  4. Track Cloud Maturity Beyond Tech

    • Evaluate cultural aspects: e.g., dev empowerment, cost accountability, user feedback loops.
    • Revisit or revise success criteria every 6-12 months.

  5. Recognise and Reward Cloud Champions

    • Publicly celebrate individuals or squads who pioneer new solutions, demonstrate cost savings, or deliver advanced workloads in HPC or serverless.

By scaling innovation hubs, open-sourcing solutions, implementing real-time compliance guardrails, tracking maturity across cultural dimensions, and publicly recognising cloud champions, you cement a thriving, cloud-first culture that embraces experimentation, security, and strategic public sector outcomes.

Keep doing what you’re doing, and consider publishing blog posts or opening pull requests to share your experiences in fostering a cloud-first mindset under strong executive sponsorship. This helps others in the UK public sector replicate or learn from your advanced leadership-driven cloud transformation.

Security

How does your organisation authenticate and manage non-human service accounts?

Basic User/Pass Credentials: Non-human service accounts are managed using basic ID/secret pair credentials, with a user/password approach.

How to determine if this good enough

In this scenario, your organisation creates standard user accounts (with a username/password) for services or scripts to authenticate within the cloud environment. It might be “good enough” if:

  1. Minimal Cloud Usage

    • Only a few workloads exist, and they don’t require advanced identity/access management or rigorous security controls.

  2. Low-Risk Services

    • The data or resources accessed by these service accounts do not involve sensitive citizen data or mission-critical infrastructure.

  3. No Internal Skill for Advanced Approaches

    • The team lacks time or resources to implement more secure methods of service account authentication.

However, user/password-based credentials can be easily leaked or shared, risking unauthorised access. NCSC’s Cloud Security Guidance and NIST SP 800-63 on digital identity guidelines often advise stronger or more automated credential management to avoid credential sprawl or reuse.

How to do better

Below are rapidly actionable steps to enhance service account security beyond basic user/pass credentials:

  1. Use Cloud-Native IAM for Service Accounts

  2. Adopt a Central Secret Manager

  3. Automate Rotation

    • If you must keep user/pass-based secrets temporarily, implement at least monthly or quarterly rotations:
      • Minimises window of exposure if leaked.

  4. Reference NCSC & NIST

  5. Plan for Future Migration

    • Target short-lived tokens or IAM role-based approaches as soon as feasible, phasing out permanent user credentials for non-human accounts.

By employing a secure secret manager, rotating basic credentials, and gradually moving to role-based or short-lived tokens, you significantly reduce the risk associated with static user/password pairs for service accounts.

API Key Usage: Non-human service accounts are authenticated using API keys, which are less dynamic and might have longer lifespans.

How to determine if this good enough

If your service accounts rely on API keys for authentication—commonly found in scripts or CI/CD jobs—this might be acceptable if:

  1. Limited Attack Surface

    • The system is small-scale, and your keys do not provide broad or highly privileged access.

  2. Reasonable Operational Constraints

    • You only occasionally manage these keys, storing them in private repos or basic secret storage.

  3. No Strict Security/Compliance Mandates

    • You’re not handling data that triggers heightened security or compliance requirements beyond basic standards.

However, API keys can be compromised if not rotated or stored carefully. NCSC’s guidance on credential hygiene recommends more dynamic or short-lived solutions. Similarly, [NIST SP 800-63] suggests limited-lifespan credentials for improved security.

How to do better

Below are rapidly actionable ways to move beyond static API keys:

  1. Store Keys in a Central Secret Manager

  2. Automate API Key Rotation

    • Implement a rotation schedule (e.g., monthly or quarterly) or on every deployment:
      • Reduces the window if a key is leaked.

  3. Consider IAM Role or Token-Based Alternatives

  4. Limit Scopes

  5. Log & Alert on Key Usage

By centrally managing keys, rotating them automatically, transitioning to role-based or token-based credentials, enforcing least privilege, and auditing usage, you substantially reduce the security risk associated with static API keys.

Centralised Secret Store with Some Credential Rotation: A central secret store is in place, possibly supporting automated rotation of credentials for some systems, enhancing security and management efficiency.

How to determine if this good enough

Your organisation employs a central solution (like AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, or OCI Vault) to hold service account credentials. Some credentials rotate automatically, while others might still be static. This might be “good enough” if:

  1. Enhanced Security Posture

    • You have significantly reduced the chance of plain-text credentials being lost or shared in code repos.

  2. Operational Efficiency

    • Teams no longer manage credentials ad hoc. The secret store offers a single source for retrieving keys, tokens, or passwords.

  3. Some Automated Rotation

    • Certain credentials—like RDS, database, or particular account keys—rotate on a schedule, improving security.

To further strengthen security, you could expand rotation across all credentials, adopt advanced ephemeral tokens, or integrate mutual TLS. NCSC’s guidance on secrets management and zero-trust approaches supports such expansions.

How to do better

Below are rapidly actionable ways to refine a centralised secret store with partial rotation:

  1. Extend Rotation to All or Most Credentials

    • If some are still static, define a plan for each credential’s rotation frequency:
      • e.g., monthly or upon every production deployment.

  2. Build Automated Pipelines

  3. Enforce Access Policies

  4. Combine with Role-Based Authentication

  5. Monitor for Stale or Unused Secrets

    • Regularly check your secret store for credentials not accessed in a while or older than a certain rotation threshold:
      • helps avoid accumulating outdated secrets.

By expanding automated rotation, integrating secret retrieval into pipelines, enforcing tight access controls, adopting role-based methods for new services, and cleaning stale secrets, you further strengthen your centralised secret store approach for secure, efficient credential management.

Mutual TLS for Authentication: Mutual Transport Layer Security (mTLS) is used for non-human service accounts, providing a more secure, certificate-based authentication method.

How to determine if this good enough

Your organisation deploys mutual TLS (mTLS)—each service has a certificate, and the server also presents a certificate to the client, ensuring bidirectional trust. This may be “good enough” if:

  1. Secure End-to-End

    • Services handle particularly sensitive data (e.g., health records, citizen data) requiring robust authentication.

  2. Compliance with Zero-Trust or Strict Policies

  3. Operational Maturity

    • You maintain a solid PKI or certificate authority infrastructure, rotating and revoking certificates as needed.

However, implementing mTLS can be complex, requiring thorough certificate lifecycle management and robust observability. You might refine usage by embedding short-lived, dynamic certificates or adopting service mesh solutions that automate mTLS.

How to do better

Below are rapidly actionable ways to improve your mTLS-based authentication approach:

  1. Short-Lived Certificates

  2. Adopt a Service Mesh

    • If using microservices in Kubernetes, incorporate [Istio, Linkerd, or AWS App Mesh, Azure Service Mesh, GCP Anthos Service Mesh, OCI OKE integrated mesh] to handle mTLS automatically:
      • Enforces consistent policies across services.

  3. Implement Strict Certificate Policies

  4. Monitor for Expiry and Potential Compromises

  5. Combine with IAM for Additional Controls

    • For advanced zero-trust, complement mTLS with role-based or token-based checks:
      • e.g., verifying principal claims in addition to cryptographic identities.

By employing short-lived certs, possibly using a service mesh, establishing strict certificate policies, continuously monitoring usage, and optionally layering further IAM or token checks, you maximise the security benefits of mTLS for your service accounts.

Short-Lived, Federated Identities with Strong Verification: Non-human service accounts use short-lived, federated identities that are strongly verifiable and validated with each request, ensuring a high level of security and minimising the risk of credential misuse.

How to determine if this good enough

Your approach for non-human accounts employs ephemeral tokens or federated identity solutions—limiting each credential’s lifespan and ensuring each request is securely verified. You might see it “good enough” if:

  1. Zero Standing Privileges

    • No permanent credentials exist. Each service obtains a short-lived token or identity just before usage.

  2. Granular, Real-Time Validation

  3. High Assurance of Security

    • The risk of stolen or misused credentials is drastically reduced, as tokens expire rapidly.

Though highly advanced, you might further optimise performance, adopt specialised identity standards (e.g., OAuth2, JWT-based systems), or integrate with multi-cloud identity solutions. NCSC’s and NIST’s advanced DevSecOps suggestions encourage ongoing improvement in ephemeral, short-lived identity usage.

How to do better

Even at this top level, below are rapidly actionable refinements:

  1. Leverage Vendor Identity Federation Tools

    • e.g., [AWS IAM roles with Web Identity Federation or AWS Secure Token Service, Azure AD token issuance, GCP IAM federation, OCI Identity Federation with IDCS], ensuring minimal friction for ephemeral tokens.

  2. Integrate Policy-as-Code

    • Tools like [Open Policy Agent or vendor policy engines (AWS SCP, Azure Policy, GCP Organisation Policy, OCI Security Zones)] can dynamically evaluate each identity request in real time.

  3. Adopt Service Mesh with Dynamic Identity

    • In container or microservice architectures, pair ephemeral identity with a service mesh that injects secure tokens automatically.

  4. Continuously Audit and Analyze Logs

  5. Cross-Government Federated Services

By fully harnessing vendor identity federation, embedding policy-as-code, integrating ephemeral identity usage in service meshes, analyzing usage logs for anomalies, and considering cross-government identity solutions, you refine an already highly secure and agile environment for non-human service accounts aligned with best-in-class public sector practices.

Keep doing what you’re doing, and consider publishing blogs or opening pull requests to this guidance about your success in elevating non-human identity security in cloud environments. Sharing your experiences helps other UK public sector organisations adopt robust credential management aligned with the highest security standards.

How does your organisation authenticate and manage user identities?

Basic or No Identity Policies: There are limited or no organisation-wide identity policies, such as password policies, with minimal audit or enforcement mechanisms to ensure compliance.

How to determine if this good enough

Your organisation may lack formal identity and password guidelines, or each team creates ad hoc rules. This might be seen as acceptable if:

  1. Minimal Access Needs

    • Only a handful of staff use cloud resources, making the risk of misconfiguration or credential sharing relatively low.

  2. No Strict Compliance

    • You operate in an environment where official audits or regulatory demands for identity controls are currently absent.

  3. Limited Cloud Adoption

    • You are still at an exploratory stage, so formalising identity policies hasn’t been prioritised yet.

However, lacking standard policies can result in weak or inconsistent credential practices, inviting security breaches. NCSC’s Password Guidance and NIST SP 800-63 on digital identity guidelines emphasize robust policy frameworks to mitigate credential-based threats.

How to do better

Below are rapidly actionable suggestions to introduce at least a minimal level of identity governance:

  1. Define a Basic Password/Passphrase Policy

    • For instance, require passphrases of at least 14 characters, no enforced complexity that leads to repeated password re-use.
    • Consult NCSC’s password guidance for recommended best practices.

  2. Centralise Authentication for Cloud Services

  3. Start Logging Identity Events

  4. Establish a Simple Governance Policy

  5. Plan for Incremental Improvement

    • Mark out a short timeline (e.g., 3-6 months) to adopt multi-factor authentication for privileged or admin roles next.

By introducing a foundational password policy, centralising authentication, enabling basic identity event logging, creating a minimal governance document, and scheduling incremental improvements, you’ll rapidly move beyond ad hoc practices toward a more secure, consistent approach.

Manual Identity Policy Enforcement: While a common set of identity policies may exist, their enforcement and audit rely on manual efforts, such as retrospective analysis of logs or reports.

How to determine if this good enough

Your organisation has some formal rules for passwords, MFA, or user provisioning, but verifying compliance requires manual checks, sporadic log reviews, or retrospective audits. You might see it “good enough” if:

  1. Limited-Scale or Low Risk

    • You can manage manual checks if you have fewer user accounts or only a small set of privileged users.

  2. Existing Staff Processes

    • The team can handle manual policy checks (like monthly password rotation reviews), although it’s time-consuming.

  3. No Immediate Audit Pressures

    • You have not recently encountered external security audits or compliance enforcements that require continuous, automated reporting.

While this approach fosters some consistency, manual processes often fail to catch misconfigurations promptly, risking security lapses. NCSC’s identity management best practices and NIST frameworks generally advise automation to quickly detect and address policy violations.

How to do better

Below are rapidly actionable ways to automate and strengthen your identity policy enforcement:

  1. Deploy Automated Audits

  2. Enforce Basic MFA for Privileged Accounts

  3. Establish Self-Service or Automated Access Reviews

    • Implement a monthly or quarterly identity review:
      • e.g., a simple emailed listing of who has what roles, requiring managers to confirm or revoke access.

  4. Adopt Single Sign-On (SSO)

  5. Store Policies & Logs in a Central Repo

    • Keep your identity policy in version control and track changes:

By automating audits, enforcing MFA, implementing automated access reviews, consolidating sign-on, and centralising policy documentation, you move from manual enforcement to a more efficient, consistently secure identity posture.

Partially Automated Identity Management: Organisation-wide identity policies, including 2FA/MFA for privileged accounts, are in place. Audit and enforcement processes are partially automated.

How to determine if this good enough

You have implemented some automation for identity management—like requiring 2FA for admin roles and using scripting or built-in cloud tools for scanning compliance. It might be “good enough” if:

  1. Reduction in Manual Oversight

    • Automated checks detect certain policy violations or stale accounts, though not everything is covered.

  2. Broader Governance

    • The organisation has standard identity controls. Teams typically follow them, but some manual interventions remain.

  3. Improved Security Baseline

    • Regular or partial identity audits reveal fewer misconfigurations or abandoned accounts.

You still can refine these partial automations to fully handle user lifecycle management, integrate single sign-on for all users, or adopt real-time security responses. NIST SP 800-53 AC controls and NCSC identity recommendations consistently recommend deeper automation.

How to do better

Below are rapidly actionable ways to progress toward advanced identity automation:

  1. Expand MFA Requirements to All Users

    • If only privileged users have 2FA, consider rolling out to all staff or external collaborators:
      • e.g., AWS, Azure, GCP, OCI support TOTP apps, hardware security keys, or SMS as fallback (not recommended if higher security needed).

  2. Use Role/Attribute-Based Access

    • For each environment (AWS, Azure, GCP, OCI), define roles or groups with appropriate privileges:

  3. Consolidate Identity Tools

  4. Integrate Automated Deprovisioning

  5. Enhance Monitoring & Alerting

    • Add real-time alerts for suspicious identity events:
      • e.g., multiple failed logins, sudden role escalations, or new key creation.

By extending MFA to all, embracing role-based access, consolidating identity management, automating deprovisioning, and boosting real-time monitoring, you achieve more robust, near-seamless identity automation aligned with best practices for public sector security.

Advanced and Mostly Automated Identity Management: Centralised identity policies and audit procedures, possibly including 2FA/MFA for all users and leveraging Single Sign-On (SSO). Most audit and enforcement activities are automated.

How to determine if this good enough

Here, your organisation enforces a centralised identity solution with automated checks. Some manual steps may remain for edge cases, but 2FA or SSO is standard for all staff. This approach might be “good enough” if:

  1. High Standardisation

    • All departments follow a uniform identity policy, with minimal exceptions.

  2. Frequent Automated Audits

    • Tools or scripts detect anomalies (e.g., unused accounts, role expansions) and flag them without manual effort.

  3. User-Friendly SSO

    • Staff log in once, accessing multiple cloud services, ensuring better compliance with security measures (like forced MFA).

Though highly mature, you can further refine short-lived credentials for non-human accounts, adopt advanced or zero-trust patterns, and integrate additional threat detection. NIST SP 800-207 zero-trust architecture guidelines and NCSC cloud security frameworks suggest continuous iteration.

How to do better

Below are rapidly actionable steps to elevate advanced identity management:

  1. Adopt Conditional Access or Policy-based Access

  2. Incorporate Just-In-Time (JIT) Privileges

    • For admin tasks, require users to elevate privileges temporarily:
      • e.g., AWS IAM Permission boundaries, Azure Privileged Identity Management, GCP short-lived access tokens, OCI dynamic roles with short-lived credentials.

  3. Monitor Identity with SIEM or Security Analytics

    • e.g., [AWS Security Hub, Azure Sentinel, GCP Security Command Center, OCI Logging Analytics] for real-time anomaly detection or advanced threat intelligence:
      • Ties into your identity logs to detect suspicious patterns.

  4. Engage in Regular “Zero-Trust” Drills

  5. Promote Cross-Government Identity Standards

By implementing conditional or JIT access, leveraging robust SIEM-based identity monitoring, holding zero-trust scenario drills, and sharing identity solutions across the public sector, you further strengthen an already advanced identity environment.

Fully Centralised and Automated Identity Management: Comprehensive, fully centralised identity policies and audit procedures with complete automation in enforcement. Policies encompass enterprise-standard MFA and SSO. Automated certification processes for human users and system accounts are in place, especially for accessing sensitive data, along with on-demand reporting capabilities.

How to determine if this good enough

Your organisation has reached the top maturity level, with a fully centralised, automated identity management solution. You might see it “good enough” if:

  1. Enterprise-Grade IAM

    • Every user (human or non-human) is governed by a central directory, applying strong MFA/SSO, with role-based or attribute-based controls for all resources.

  2. Zero Standing Privilege

    • Privileged credentials are ephemeral, enforced by JIT or automated workflows.
    • Minimises exposure from compromised accounts.

  3. Continuous Compliance & Reporting

    • Real-time dashboards or logs show who can access what, enabling immediate audits for regulatory or internal policy checks.

  4. Seamless Onboarding & Offboarding

    • Automated provisioning grants roles upon hire or team assignment, revoking them upon departure to ensure no orphaned accounts.

Though highly advanced, you can refine multi-cloud identity federation, adopt specialised HPC/AI or cross-government identity sharing, and embed advanced DevSecOps patterns. NCSC’s security architecture advice and [NIST SP 800-53] encourage continuous improvement in a dynamic threat landscape.

How to do better

Even at the apex, below are rapidly actionable ways to further optimise:

  1. Multi-Cloud Single Pane IAM

    • If you use multiple cloud providers, unify them under a single identity provider or a cross-cloud identity framework:
      • e.g., Azure AD for AWS + Azure + GCP roles, or a third-party IDaaS solution with robust zero-trust policies.

  2. Advanced Risk-Based Authentication

  3. Adopt Policy-as-Code for Identity

    • Tools like [Open Policy Agent or vendor policy frameworks (AWS Organizations SCP, Azure Policy, GCP Organization Policy, OCI Security Zones)] to define identity controls in code:
      • Facilitates versioning, review, and auditable changes.

  4. Extend 2FA to Cross-Government Collaboration

  5. Publish Regular Identity Health Reports

    • Summaries of user activity, stale accounts, or re-certifications. Encourages transparency and fosters trust in your identity processes.

By unifying multi-cloud identity, implementing advanced risk-based authentication, using policy-as-code for identity controls, expanding cross-government 2FA, and regularly reporting identity health metrics, you maintain a cutting-edge identity management ecosystem. This ensures robust security, compliance, and agility for your UK public sector organisation in an evolving threat environment.

Keep doing what you’re doing, and consider writing up your experiences, success metrics, or blog posts on advanced identity management. Contribute pull requests to this guidance or other best-practice repositories so fellow UK public sector entities can learn from your identity management maturity journey.

How does your organisation ensure that users have appropriate permissions aligned with their roles?

Ad-Hoc and Informal Review Process: User entitlements and profiles are reviewed in an ad-hoc, informal manner with administrators manually managing these as they see fit.

How to determine if this good enough

Your organisation lacks a formal or scheduled approach to verifying user access, relying on admin discretion. This might be acceptable if:

  1. Small or Static Environments

    • Fewer staff changes, so new or removed accounts are manageable without a structured process.

  2. No Critical Data or Systems

    • Low sensitivity or risk if accounts remain overprivileged or are never deactivated.

  3. Minimal Budgets/Resources

    • The current state is all you can handle, with no immediate impetus to formalise.

However, ad-hoc reviews often result in outdated or excessive privileges, violating the NCSC’s principle of least privilege and ignoring NIST SP 800-53 AC (Access Control) controls. This can lead to security breaches or cost inefficiencies.

How to do better

Below are rapidly actionable steps to transition from ad-hoc reviews to basic structured processes:

  1. Define a Minimal Access Policy

  2. Create a Simple RACI for Access Management

    • Identify who is Responsible, Accountable, Consulted, and Informed for each step (e.g., granting, revoking, auditing).
    • Helps clarify accountability if something goes wrong.

  3. Leverage Built-In Cloud IAM Tools

  4. Maintain a Basic User Inventory

    • Keep a spreadsheet or list of all privileged users, what roles they have, and last update date:
      • So you can spot dormant accounts or over-privileged roles.

  5. Plan for Periodic Checkpoints

    • Commit to a small monthly or quarterly access sanity check with relevant admins, reducing overlooked issues over time.

By laying out a minimal access policy, assigning RACI for administration, adopting cloud-native IAM, maintaining a simple user inventory, and scheduling monthly or quarterly check-ins, you’ll quickly improve from ad-hoc reviews to a more reliable approach.

Periodic Manual Reviews with Limited Action: Periodic manual reviews of access rights are conducted for some systems, but access is rarely revoked or reduced due to concerns about unintended consequences.

How to determine if this good enough

Your organisation periodically inspects user entitlements—maybe annually or every six months—but rarely adjusts them, fearing interruptions if privileges are revoked. This might be considered “good enough” if:

  1. Basic Governance in Place

    • At least you have a schedule or routine for checking access.

  2. Minimal Overhead

    • The burden of frequent changes or potential disruptions might exceed perceived risk from leftover permissions.

  3. No Evidence of Abuse

    • If you haven’t encountered security incidents or cost leaks due to over-privileged accounts.

Yet continuously retaining excessive privileges invites risk. NCSC’s guidelines and NIST SP 800-53 AC-6 on least privilege emphasize actively removing unneeded privileges to shrink your attack surface.

How to do better

Below are rapidly actionable ways to evolve beyond limited-action reviews:

  1. Mandate a “Test Before Revoke” Procedure

    • If concerns about “breaking something” hinder revocations, adopt a short test environment to confirm the user or system truly needs certain permissions.

  2. Categorise Users by Risk

  3. Implement Review Dashboards

    • Summarise each user’s privileges, last login, or role usage:
      • If certain roles are not used in X days, consider removing them.

  4. Show Leadership Examples

    • Have a pilot case where you successfully reduce access for a role with no negative consequences, building confidence.

  5. Incentivise or Recognise Proper Clean-Up

    • Acknowledge teams or managers who diligently remove no-longer-needed permissions:
      • Encourages a habit of safe privilege reduction.

By adopting test environments before revoking privileges, classifying user risk levels, building simple dashboards, demonstrating safe revocations, and recognising best practices, you reduce hesitancy and further align with security best practices.

Regular Manual Reviews, Primarily Additive: Regular, manual reviews of access rights are conducted across most systems. However, changes to access are generally additive rather than reductive.

How to determine if this good enough

Your organisation systematically checks user access on a regular basis, but typically only grants new privileges (additive changes). Rarely do you remove or reduce existing entitlements. This may be “good enough” if:

  1. Frequent or Complex Role Changes

    • Staff rotate roles or new tasks come up often, so you keep adding privileges to accommodate new responsibilities.

  2. Better Than Irregular Audits

    • At least you’re reviewing systematically, capturing some improvements over purely ad-hoc or partial reviews.

  3. No Major Security Incidents

    • You haven’t experienced negative consequences from leftover or stale permissions yet.

However, purely additive processes lead to privilege creep. Over time, users accumulate broad access, conflicting with NCSC’s least privilege principle and NIST SP 800-53 AC-6 compliance. Reductions are vital to maintain a minimal attack surface.

How to do better

Below are rapidly actionable steps to incorporate permission reduction:

  1. Implement a “Use it or Lose it” Policy

  2. Mark Temporary Access with Expiry

    • For short-term projects, set an end date for extra privileges:
      • e.g., using AWS or Azure policy conditions, GCP short-lived tokens, or OCI compartments-based ephemeral roles.

  3. Combine with Slack/Teams Approvals

    • Automate revocation requests: if an admin sees stale permissions, they click a button to remove them, and a second manager approves:
      • Minimises fear of accidental breakage.

  4. Reward “Right-sizing”

    • Celebrate teams that proactively reduce permission sprawl, referencing cost savings or risk reduction:
      • e.g., mention in staff newsletters or internal security updates.

  5. Refine Review Frequency

    • If reviews are monthly or quarterly, consider stepping up to weekly or adopting a continuous scanning approach for business-critical accounts.

By adding a usage-based revocation policy, setting expiry for short-lived roles, integrating quick approval workflows, recognising teams that successfully remove unused privileges, and potentially increasing review frequency, you shift from additive-only changes to an environment that truly enforces minimal privileges.

Regular Reviews with Defined Expiry Dates: Access is regularly reviewed, certified, and remediated. Role allocations include defined expiry dates, necessitating review and re-certification.

How to determine if this good enough

Your organisation systematically reviews user access with clear renewal or expiry deadlines, ensuring no indefinite privileges. This indicates a strong security posture. It’s likely “good enough” if:

  1. Automated or Well-Managed Reviews

    • The process is consistent, with each role or permission requiring re-validation after a certain period.

  2. Minimal Privilege Creep

    • Because roles expire, staff or contractors do not accumulate unneeded rights over time.

  3. High Confidence in Access Data

    • You maintain accurate data on who has which roles, and changes occur only after formal approval or re-certification.

Though robust, you can further refine by integrating real-time risk signals or adopting advanced identity analytics. NCSC’s operational resilience and NIST SP 800-53 Access Controls (AC-2, AC-3) generally encourage continuous improvement in automated checks.

How to do better

Below are rapidly actionable methods to enhance expiry-based reviews:

  1. Use Cloud-Native Access Review Tools

  2. Adopt Automated Alerts for Upcoming Expiries

    • If a role is nearing its expiry date, the user and manager receive an email or Slack notice to re-certify or let it lapse.

  3. Incorporate Risk Scoring

    • If an account has high privileges or sensitive system access, require more frequent or thorough re-validation:
      • e.g., monthly for privileged accounts, quarterly for standard user roles.

  4. Implement Delegated Approvals

  5. Maintain Audit Trails

By leveraging cloud-native review tools, alerting for soon-to-expire roles, risk-scoring high-privilege accounts for more frequent checks, implementing delegated re-approval processes, and storing thorough audit trails, you maintain an agile, secure environment aligned with best practices.

Automated, Risk-Based Access Reviews: Fully integrated, automated reviews ensure users have permissions appropriate to their roles. Access rights are dynamically adjusted based on role changes or review outcomes. Both access roles and their allocations have expiry dates for mandatory review and re-certification.

How to determine if this good enough

At the apex of maturity, your organisation uses a fully automated, risk-based system for managing user permissions. You might consider it “good enough” if:

  1. Zero Standing Privileges

    • Privileges are automatically granted, adjusted, or revoked based on real-time role changes, with minimal human intervention.

  2. Frequent or Continuous Verification

    • A system or pipeline regularly checks each user’s entitlements, triggers escalations if anomalies arise.

  3. Synchronised with HR Systems

    • Staff transitions—new hires, promotions, departures—instantly reflect in user permissions, preventing orphaned or leftover access.

  4. Strong Governance

Although highly mature, you can still enhance cross-government collaboration or adopt real-time risk-based authentication. NCSC’s zero-trust architecture or advanced DevSecOps suggestions encourage ongoing adaptation to new technology or threat vectors.

How to do better

Below are rapidly actionable ways to refine a fully automated, risk-based review system:

  1. Incorporate Real-Time Risk Signals

  2. Use Policy-as-Code for Access

    • Tools like [Open Policy Agent or vendor-based solutions (AWS Organizations SCP, Azure Policy, GCP Organization Policy, OCI Security Zones)] can define rules for dynamic role allocation.

  3. Ensure Continuous Oversight

    • Provide dashboards for leadership or security officers, showing current risk posture, overdue re-certifications, or upcoming role changes:
      • Minimises the chance of an overlooked anomaly.

  4. Extend to Multi-Cloud or Hybrid

    • If your department spans AWS, Azure, GCP, or on-prem systems, unify identity reviews under a single orchestrator or Identity Governance tool:

  5. Cross-Government Sharing

By integrating real-time risk analysis, employing policy-as-code for dynamic role assignment, offering continuous oversight dashboards, supporting multi-cloud/hybrid scenarios, and sharing insights across government bodies, you further refine an already advanced, automated identity review system. This ensures minimal security risk and maximum agility in the public sector context.

Keep doing what you’re doing, and consider publishing blog posts or making pull requests to this guidance about your advanced access review processes. Sharing experiences helps other UK public sector organisations adopt similarly robust, automated solutions for managing user permissions.

How does your organisation handle user provisioning for cloud systems, focusing on authentication for human users?

Shared Accounts and Manual Account Management: Accounts are shared or reused between multiple people with limited ability to discern who carried out an action from any logs collected. Where individual accounts exist for each user they are manually created, deleted, updated, and assigned, involving significant manual effort and potential for inconsistency.

How to determine if this good enough

Your organisation might rely on shared or manually managed individual accounts for cloud systems, with minimal traceability. This can feel “good enough” if:

  1. Minimal Operational Complexity

    • The cloud usage is small-scale, and staff prefer quick, ad-hoc solutions.

  2. Limited or Non-Critical Workloads

    • The risk from poor traceability is low if the environment does not hold sensitive data or mission-critical services.

  3. Short-Term or Pilot

    • You see the current manual or shared approach as a temporary measure during initial trials or PoCs.

However, sharing accounts blurs accountability, violates NCSC’s principle of user accountability and contravenes NIST SP 800-53 AC-2 for unique identification. Manually managing accounts can also lead to mistakes (e.g., failing to revoke ex-employee access).

How to do better

Below are rapidly actionable steps to move beyond shared/manual accounts:

  1. Eliminate Shared Accounts

    • Mandate each user has an individual account, referencing NCSC’s identity best practices.
    • This fosters actual accountability and compliance with typical public sector guidelines.

  2. Set Up Basic IAM

  3. Document a Minimal Process

  4. Enable Basic Audit Logging

  5. Move to a Single Sign-On Approach

    • Plan to adopt SSO with a single user directory in the next phase:
      • Minimises manual overhead and ensures consistency.

By ensuring each user has an individual account, using vendor IAM for creation, documenting a minimal lifecycle process, enabling audit logging, and preparing for SSO, you remedy the major pitfalls of shared/manual account approaches.

Identity Repository with Manual Processes: An organisational identity repository (like Active Directory or LDAP) is used as the user source of truth, but processes for cloud system integration are manual or inconsistent.

How to determine if this good enough

Your organisation might store all user info in a standard directory (e.g., Active Directory or LDAP) but each cloud integration is handled manually. This can be “good enough” if:

  1. Consistent On-Prem Directory

    • You can reliably create and remove user entries in your on-prem directory, so internal processes generally work.

  2. Limited Cloud Footprint

    • Only a few cloud services rely on these user accounts, so manual processes don’t create major friction.

  3. Medium Risk Tolerance

    • The environment accepts manual integrations, though certain compliance or security requirements aren’t strict.

However, manual synchronisation or ad-hoc provisioning to cloud systems often leads to out-of-date accounts, security oversights, or duplication. NCSC’s identity and access management guidance and NIST SP 800-53 AC (Access Controls) recommend consistent, automated user lifecycle management across on-prem and cloud.

How to do better

Below are rapidly actionable steps to unify and automate your on-prem identity repository with cloud systems:

  1. Enable Federation or SSO

  2. Deploy Basic Automation Scripts

    • If a full federation is not possible immediately, create scripts that read from your directory and auto-provision or auto-delete accounts in cloud:
      • e.g., using vendor CLIs or REST APIs.

  3. Standardise User Roles

    • For each cloud environment, define roles that map to on-prem groups:
      • e.g., “Developer group in AD -> Dev role in AWS.”
    • Ensures consistent privileges across systems, referencing NCSC’s least-privilege principle.

  4. Implement a Scheduled Sync

    • Regularly compare your on-prem directory with each cloud environment to detect orphaned or mismatch accounts.
    • Could be monthly or weekly initially.

  5. Transition to Identity Provider Integration

By federating or automating the sync between your directory and cloud, standardising roles, scheduling periodic comparisons, and eventually adopting a modern identity provider, you gradually remove manual friction and potential security gaps.

Common Standards for Identity Management: Standardised protocols and practices are in place for managing and mapping user identities between identity providers and cloud systems. Non-compliant services are less preferred.

How to determine if this good enough

Your organisation has established guidelines for user provisioning, adopting standard protocols (e.g., SAML, OIDC) or dedicated identity bridging solutions. This is likely “good enough” if:

  1. Consistent Approach

    • Teams or new projects follow the same identity integration pattern, reducing one-off solutions.

  2. Moderate Automation

    • User accounts typically auto-provision or sync from a central IDP, though some edge cases may require manual effort.

  3. Reduced Shadow IT

You may strengthen these standards by further automating account lifecycle, ensuring short-lived credentials for privileged tasks, or integrating advanced analytics for anomaly detection. [NIST SP 800-63 or 800-53] highlight deeper identity proofing and continuous monitoring strategies.

How to do better

Below are rapidly actionable ways to refine standard identity management:

  1. Require SSO or Federation for All Services

  2. Implement Access Workflows

  3. Continuously Evaluate Cloud Services

    • Maintain a whitelist of services that meet your identity standards:
      • If a service can’t integrate with SSO or can’t match your password/MFA policies, strongly discourage its use.

  4. Include Role Mapping in a Central Catalog

  5. Expand Logging & Alerting

By enforcing SSO/federation for all services, deploying structured access workflows, continuously evaluating new cloud offerings, documenting role-to-privilege mappings, and bolstering security alerting, you ensure consistent, secure user identity alignment across your cloud ecosystem.

Automated Federated Identity Management: Federated identity management is fully automated, ensuring consistent user provisioning across all systems. Non-compliant services are isolated with appropriate mitigations.

How to determine if this good enough

Your organisation’s identity is seamlessly managed by a central provider, with minimal manual intervention:

  1. Automatic User Lifecycle

    • Hiring, role changes, or terminations sync instantly to cloud services—no manual updates needed.

  2. Strong Policy Enforcement

    • Services without SAML/OIDC or SCIM compliance are either disallowed or strictly sandboxed.

  3. Robust Security & Efficiency

You might further refine by adopting ephemeral credentials or advanced risk-based access policies. NIST SP 800-207 zero trust architecture suggests dynamic, continuous verification of user sessions.

How to do better

Below are rapidly actionable ways to reinforce automated federated identity:

  1. Adopt Short-Lived Credentials

  2. Implement Policy-as-Code for Identity

  3. Add Real-Time Security Monitoring

    • If a user tries to access a new or high-risk service, enforce additional checks:
      • e.g., multi-factor step-up, manager approval, location-based restrictions.

  4. Integrate Cross-department SSO

    • If staff frequently collaborate across multiple public sector agencies, explore cross-government identity solutions:
      • e.g., bridging Azure AD tenants or adopting solutions that unify NHS, local council, or central government credentials.

  5. Review & Update Roles Continuously

    • Encourage monthly or quarterly role usage analyses, removing unneeded entitlements automatically:
      • Minimises risk from leftover privileges.

By adopting short-lived credentials, storing identity policy in code, enabling real-time security checks, exploring cross-department SSO, and continuously reviewing role usage, you transform a solid federation setup into a robust and adaptive identity ecosystem.

Unified Cloud-Based Identity Provider: A fully cloud-based user directory or identity provider acts as the single source of truth. Centralised management is aligned with user onboarding, movements, and terminations. Services not supporting federated identity have been phased out.

How to determine if this good enough

At the highest maturity, your organisation uses a single, cloud-based IdP (e.g., Azure AD, AWS SSO, GCP Identity, or third-party SSO) for all user lifecycle events, and systems not integrating with it are deprecated or replaced. You might see it “good enough” if:

  1. Complete Lifecycle Automation

    • All new hires automatically get relevant roles, moving staff trigger role changes, and departures instantly remove access.

  2. Zero Trust & Full Federation

    • Every service or app you rely on supports SAML, OIDC, or SCIM, leaving no manual provisioning.

  3. Strong Compliance & Efficiency

Even so, you can continuously refine cross-department identity, advanced DevSecOps integration, or adopt next-gen identity features (e.g., risk-based authentication or passwordless technologies).

How to do better

Below are rapidly actionable ways to refine an already unified, cloud-based identity approach:

  1. Implement Passwordless or Phishing-Resistant MFA

  2. Add Dynamic Risk Scoring

  3. Extend Identity to Third-Party Collaboration

  4. Encourage Cross-Public Sector Federation

  5. Regularly Assess Identity Posture

By adopting passwordless MFA, integrating dynamic risk scoring, enabling external collaborator identity, exploring cross-public sector federation, and performing continuous zero-trust posture checks, you achieve an exceptionally secure, efficient environment—exemplifying best practices for user provisioning and identity management in the UK public sector.

Keep doing what you’re doing, and consider publishing blog posts or opening pull requests to share your experiences in creating a unified, cloud-based identity approach. By collaborating with others in the UK public sector, you help propagate secure, advanced authentication practices across government services.

How does your organisation manage authentication for non-human service accounts in cloud systems?

Human-like Accounts for Services: Non-human service accounts are set up similarly to human accounts, with long-lived credentials that are often shared.

How to determine if this good enough

Your organisation may treat service accounts as if they were human users, granting them standard usernames and passwords (or persistent credentials). This might be acceptable if:

  1. Low-Risk, Low-Criticality Services

    • The services run minimal workloads without high security, compliance, or cost risks.

  2. No Complex Scaling

    • You rarely spin up or down new services, so manual credential management seems manageable.

  3. Very Small Teams

    • Only a handful of people need to coordinate these credentials, reducing the chance of confusion.

However, long-lived credentials that mimic human user accounts typically violate NCSC’s cloud security principles and NIST SP 800-53 AC (Access Control) due to potential credential sharing, lack of accountability, and higher risk of compromise.

How to do better

Below are rapidly actionable steps to move beyond human-like accounts for services:

  1. Introduce Role-Based Service Accounts

  2. Limit Shared Credentials

    • Immediately stop creating or reusing credentials across multiple services. Assign each service a unique identity:
      • Ensures logs and auditing can differentiate actions.

  3. Enforce MFA or Short-Lived Tokens

  4. Document a Minimal Policy

  5. Begin Transition to Cloud-Native Identity

    • Plan a short-term goal (2-4 months) to retire all shared/human-like service accounts, adopting native roles or short-lived credentials where feasible.

By introducing cloud-native roles for services, eliminating shared credentials, enabling MFA or short-lived tokens if needed, documenting a minimal policy, and planning a transition, you reduce security risks posed by long-lived, human-like service accounts.

Locally Managed Long-Lived API Keys: Long-lived API keys are used for service accounts, with management handled locally at the project or program level.

How to determine if this good enough

In this setup, non-human accounts are assigned API keys (often static), managed by the project team. You might see it as “good enough” if:

  1. Limited Cross-Project Needs

    • Each project operates in isolation, with minimal external dependencies or shared services.

  2. Few Cloud Services

    • The environment is small, so local management doesn’t cause major confusion or risk.

  3. Low Security/Compliance Requirements

    • No strong obligations for rotating or logging key usage, or a short-term approach that hasn’t caught up with best practices yet.

Still, static API keys managed locally can easily be lost, shared, or remain in code, risking leaks. NCSC supply chain or credential security guidance and NIST SP 800-63 on digital identity credentials advise more dynamic, centralised strategies.

How to do better

Below are rapidly actionable steps to centralise and secure long-lived API keys:

  1. Move Keys to a Central Secret Store

  2. Enforce Rotation Policies

  3. Use Tooling for Local Key Discovery

  4. Document a Single Organisational Policy

  5. Transition to Role-Based or Short-Lived Tokens

    • While central secret storage helps, plan a future move to ephemeral tokens or IAM roles:
      • Reduces reliance on static keys altogether.

By centralising key storage, rotating keys automatically, scanning for accidental exposures, formalising a policy, and starting to shift away from static keys, you significantly enhance the security of locally managed long-lived credentials.

Centralised Secret Store for Service Accounts: A centralised repository or secret store is in place for all non-human service accounts, and its use is mandatory across the organisation.

How to determine if this good enough

Your organisation mandates storing service account credentials in a secure, central location (e.g., an enterprise secret store). This might be “good enough” if:

  1. Reduced Credential Sprawl

    • No more local storing of secrets in code or random text files.
    • Standard enforcement ensures consistent usage.

  2. Better Rotation & Auditing

  3. Strong Baseline

However, using a secret store alone doesn’t guarantee ephemeral or short-lived credentials. You can further adopt ephemeral tokens and embed attestation-based identity to limit credentials even more. NCSC’s zero trust advice also encourages dynamic authentication steps.

How to do better

Below are rapidly actionable ways to strengthen your centralised secret store approach:

  1. Automate Secret Rotation

  2. Incorporate Access Control & Monitoring

  3. Reference a “Secret Lifecycle” Document

  4. Integrate into CI/CD

    • Ensure automation pipelines fetch credentials from the secret store at build or deploy time, never storing them in code.

  5. Begin Adopting Ephemeral Credentials

By automating secret rotation, refining access controls, documenting a secret lifecycle, hooking the store into CI/CD, and planning ephemeral credentials for new services, you build on your strong foundation of centralised secret usage to minimise risk further.

Ephemeral Identities with Attestation: Service accounts do not use long-lived secrets; instead, identity is established dynamically based on attestation mechanisms.

How to determine if this good enough

Your organisation has moved beyond static credentials, using ephemeral tokens or certificates derived from environment attestation (e.g., the instance or container proves it’s authorised). This can be considered “good enough” if:

  1. Near Zero Standing Privilege

    • Non-human services only acquire valid credentials at runtime, with minimal risk of stolen or leaked credentials.

  2. Cloud-Native Security

  3. Robust Automation

You might refine or strengthen with additional zero-trust checks, rotating ephemeral credentials frequently, or adopting code-managed identities for cross-department federations. NCSC zero trust architecture guidance might suggest further synergy with policy-based access.

How to do better

Below are rapidly actionable improvements to further secure ephemeral identity usage:

  1. Embed Short-Lived Tokens in CI/CD

  2. Adopt Service Mesh or mTLS

  3. Leverage Policy-as-Code

  4. Regularly Audit Attestation Mechanisms

  5. Integrate with Cross-Org Federation

By embedding ephemeral tokens into your CI/CD, adding a service mesh or mTLS, employing policy-as-code, auditing attestation rigorously, and exploring cross-organisation federation, you evolve ephemeral identity usage into a highly secure, flexible, and zero-trust-aligned solution.

Code-Managed Identities with Federated Trust: Identities for non-human services are managed as part of the infrastructure-as-code paradigm, allowing seamless federation across the organisation without needing point-to-point trust relationships.

How to determine if this good enough

At this final level, your organisation defines service identities in code (e.g., Terraform, AWS CloudFormation, Azure Bicep, GCP Deployment Manager), and enforces trust relationships through a central identity federation. This is typically “good enough” if:

  1. Full Infrastructure as Code

    • All resource definitions, including service accounts or roles, are under version control, automatically deployed.
    • Minimises manual steps or inconsistencies.

  2. Seamless Federation

    • Multi-department or multi-cloud environments rely on a single identity trust model—no specialised per-service or per-team trust links needed.

  3. Robust Continuous Delivery

    • Automated pipelines update identities, rotating credentials or ephemeral tokens as part of routine releases.

  4. Holistic Governance & Observability

Though advanced, you may refine ephemeral solutions further, adopt advanced zero-trust posture, or integrate multi-department synergy. Continuous improvements remain essential for evolving threat landscapes.

How to do better

Below are rapidly actionable ways to enhance code-managed identities with federated trust:

  1. Incorporate Real-Time Security Policies

    • Use policy-as-code (OPA, AWS SCP, Azure Policy, GCP Org Policy, OCI Security Zones) to automatically detect and block misconfigurations in your IaC definitions.

  2. Leverage DevSecOps Workflows

    • Integrate identity code linting, security scanning, and ephemeral token provisioning into CI/CD:
      • e.g., scanning Terraform or CloudFormation for suspicious identity references before merge.

  3. Implement Zero-Trust Microsegmentation

  4. Expand to Multi-Cloud/Hybrid

    • If multiple providers or on-prem systems are used, unify identity definitions across them:

  5. Regularly Validate & Audit

By employing policy-as-code, adopting DevSecOps scanning in your pipeline, embracing zero-trust microsegmentation, extending code-based identity to multi-cloud/hybrid, and continuously auditing for drift, you perfect a code-centric model that securely and efficiently manages service identities across your entire public sector environment.

Keep doing what you’re doing, and consider sharing your approach to code-managed identity and federated trust in blog posts or by making pull requests to this guidance. This knowledge helps other UK public sector organisations adopt similarly robust, zero-trust-aligned solutions for non-human service account authentication.

How does your organisation manage risks?

Basic and Informal Risk Management: Risk management is carried out in a basic and informal manner, often relying on individual judgement without structured processes.

How to determine if this good enough

Your organisation’s risk management approach is largely ad hoc—no formal tools or consistent methodology. It might be “good enough” if:

  1. Limited Scale or Maturity

    • You run small, low-criticality projects where major incidents are rare, so an informal approach hasn’t caused big issues yet.

  2. Tight Budget or Short Timescale

    • Adopting more structured processes may currently seem out of reach.

  3. No External Compliance Pressures

    • You aren’t subject to rigorous audits requiring standardised risk registers or processes.

Nevertheless, purely informal risk management can lead to overlooked threats—particularly in cloud deployments, which often demand compliance with NCSC security guidance and NIST risk management frameworks.

How to do better

Below are rapidly actionable steps to improve from an informal approach:

  1. Create a Simple Risk Checklist

  2. Record & Communicate Regularly

    • Even a single spreadsheet or Word doc with identified risks, likelihood, and impact fosters consistency.
    • Share it monthly or quarterly with the relevant stakeholders.

  3. Assign Risk Owners

    • For each risk, name someone responsible for tracking and mitigating.
    • Prevents duplication or “everyone and no one” owning an issue.

  4. Introduce Basic Likelihood & Impact Scoring

    • e.g., 1-5 scale for likelihood, 1-5 for impact, multiply for a total risk rating.
    • This helps prioritise and start discussion around risk tolerance.

  5. Plan for Next Steps

By establishing a simple risk checklist, scheduling short reviews, assigning ownership, adopting basic scoring, and outlining a plan for incremental improvements, you quickly move from purely informal approaches to a more recognisable and consistent risk management foundation.

Ad-Hoc Spreadsheets for Risk Tracking: Risks are tracked using ad-hoc spreadsheets at the project or program level, without a standardised or centralised system.

How to determine if this good enough

Your organisation does track risks in spreadsheets, but each project manages them independently, with no overarching or centralised view. This might be “good enough” if:

  1. Limited Inter-Project Dependencies

    • Each project’s risks are fairly separate, so missing cross-program synergy or consolidated reporting doesn’t cause issues.

  2. Basic Consistency

    • Each spreadsheet might follow a similar format (like risk ID, likelihood, impact, mitigations), but there’s no single consolidated tool.

  3. Low Complexity

    • The organisation’s scale is small enough to handle manual processes, and no major audits require advanced solutions.

Spreadsheets can lead to inconsistent categories, scattered ownership, and difficulty identifying enterprise-wide risks—especially for cloud security or data privacy. NCSC guidance and NIST risk frameworks often advocate a centralised or standardised method for managing overlapping concerns.

How to do better

Below are rapidly actionable improvements:

  1. Adopt a Standardised Template

    • Provide a uniform risk register template across all projects.
    • Outline columns (e.g., risk description, category, likelihood, impact, owner, mitigations, target resolution date).

  2. Encourage Regular Cross-Project Reviews

    • Monthly or quarterly, each project lead presents top risks.
    • Creates awareness of shared or similar risks (like cloud credential leaks, compliance deadlines).

  3. Consolidate Key Risks

    • Extract major issues from each spreadsheet into a single “organisational risk summary” for senior leadership or departmental boards.

  4. Implement Basic Tool or Shared Repository

    • e.g., host a central SharePoint list, JIRA board, or Google Sheet consolidating all project-level risk inputs:
      • Minimises confusion while maintaining a single source of truth.

  5. Leverage Some Automation

By adopting a consistent template, hosting cross-project reviews, summarising top risks in an organisational-level register, using a shared tool or repository, and partly automating detection of cloud security concerns, you advance from ad-hoc spreadsheets to a more coordinated approach.

Formalised Risk Registers with Periodic Reviews: Formal risk registers are maintained for projects or programs, with risks reviewed and updated on a periodic basis.

How to determine if this good enough

Your organisation uses structured risk registers—most likely Excel-based or a simple internal tool—and schedules regular reviews (e.g., monthly or quarterly). This is likely “good enough” if:

  1. Consistent Methodology

    • Teams follow a standardised approach: e.g., risk descriptions, scoring, mitigations, owners, due dates.

  2. Regular Governance

    • Directors, program managers, or a governance board reviews and signs off on updated risks.

  3. Integration with Cloud Projects

    • Cloud-based services or migrations are documented in the risk register, capturing security, cost, or vendor concerns.

While fairly robust, you may further unify these registers across multiple programs, introduce real-time automation or advanced analytics, and incorporate risk-based prioritisation. NCSC’s operational resilience guidance and NIST SP 800-37 risk management framework advise continual refinement.

How to do better

Below are rapidly actionable ways to expand your formal risk register process:

  1. Introduce Real-Time Updates or Alerts

  2. Measure Risk Reduction Over Time

    • Track how mitigations lower risk levels. Summaries can feed departmental or board-level dashboards:
      • e.g., “Risk #12: Cloud credential leaks reduced from High to Medium after implementing MFA and secret rotation.”

  3. Encourage GRC Tools

    • Government Risk and Compliance tools can unify multiple registers:
      • e.g., ServiceNow GRC, RSA Archer, or open-source solutions.
    • Minimises duplication across large organisations or multiple projects.

  4. Link Mitigations to Budgets and Timelines

    • Where possible, highlight the cost or resource needed for each major mitigation:
      • Helps leadership see rationale for investing in e.g., staff training, new security tools.

  5. Adopt a Cloud-Specific Risk Taxonomy

    • Incorporate categories like “Data Residency,” “Vendor Lock-in,” “Cost Overrun,” or “Insecure IAM,” referencing NCSC or NIST guidelines.
    • Ensures team members identify typical cloud vulnerabilities systematically.

By setting up real-time triggers for new risks, visualising risk reduction, considering GRC tooling, linking mitigation to budgets, and classifying cloud-specific risk areas, you reinforce a structured risk registry that handles dynamic and evolving threats efficiently.

Integrated Risk Management with Central Oversight: A centralised risk management system is used, integrating risks from various projects or programs, with regular updates and reviews.

How to determine if this good enough

Your organisation has a singular system (e.g., a GRC platform) for capturing, prioritising, and reviewing risks from multiple streams, including cloud transformation efforts. It’s likely “good enough” if:

  1. Enterprise-Wide Visibility

    • Senior leadership and departmental leads see aggregated risk dashboards, no longer limited to siloed project registers.

  2. Consistent Method & Language

    • Risk scoring, categories, and statuses are uniform, reducing confusion or mismatches.

  3. Active Governance

    • A central board or committee regularly reviews top risks, ensures accountability, and drives mitigations.

To further strengthen, you may embed advanced threat intelligence or real-time monitoring data, adopt risk-based budgeting, or unify cross-department risk sharing. NCSC’s supply chain security approach and NIST ERM guidelines both mention cross-organisational alignment as vital for robust risk oversight.

How to do better

Below are rapidly actionable ways to optimise integrated, centrally overseen risk management:

  1. Incorporate Cloud-Specific Telemetry

  2. Advance Real-Time Dashboards

    • Provide live risk dashboards for each department or service, updating as soon as a risk or its mitigations change:
      • e.g., hooking up GRC tools to Slack/Teams for immediate notifications.

  3. Use Weighted Scoring for Cloud Projects

  4. Formalise Risk Response Plans

  5. Encourage Cross-department Collaboration

By integrating real-time cloud telemetry into your central risk system, offering advanced dashboards, applying specialised scoring for cloud contexts, setting formal risk responses, and cross-collaborating among agencies, you achieve deeper, more proactive risk management.

Advanced Risk Management Tool with Proactive Escalation: A shared, advanced risk management tool is in place, allowing for tracking and managing risks across multiple projects or programs. This system supports informed prioritisation and proactively escalates unacceptable risks.

How to determine if this good enough

At this final level, your organisation uses a sophisticated enterprise risk platform that automatically escalates or notifies stakeholders when certain thresholds are met. This approach is typically “good enough” if:

  1. Near Real-Time Insights

    • The tool collects data from multiple sources (e.g., CI/CD pipelines, security scans, cost anomalies) and auto-updates risk profiles.

  2. Proactive Alerts

    • If a new vulnerability emerges or usage surpasses a cost threshold, the system escalates to management or security leads.

  3. High Maturity Culture

    • Teams understand and act on risk metrics, fostering a supportive environment for quick mitigation.

Although quite mature, you might refine further by adopting advanced AI-based analytics, cross-organisation risk sharing (e.g., multi-department or local councils), or continuously updating zero-trust or HPC/AI risk frameworks. NCSC’s advanced risk guidance and NIST’s enterprise risk management frameworks suggest iterative refinement.

How to do better

Below are rapidly actionable ways to enhance an already advanced, proactive risk management system:

  1. Adopt AI/ML for Predictive Risk

  2. Integrate Risk with DevSecOps

  3. Multi-Cloud or Hybrid Risk Consolidation

    • If operating across AWS, Azure, GCP, OCI, or on-prem, unify them in one advanced GRC or SIEM tool:
      • Minimises siloed risk reporting.

  4. Extend Collaborative Risk Governance

  5. Regularly Refresh Risk Tolerance & Metrics

    • Reassess risk thresholds to ensure they remain relevant.
    • If your environment scales or new HPC/AI workloads are introduced, adapt risk definitions accordingly.

By leveraging AI for predictive risk detection, embedding risk scoring in DevSecOps pipelines, consolidating multi-cloud/hybrid risk data, collaborating on risk boards across agencies, and regularly updating risk tolerance metrics, you optimise an already advanced, proactive risk management system—ensuring continuous alignment with evolving public sector challenges and security imperatives.

Keep doing what you’re doing, and consider documenting your advanced risk management approaches through blog posts or by opening pull requests to this guidance. Sharing such experiences helps other UK public sector organisations adopt progressive risk management strategies in alignment with NCSC, NIST, and GOV.UK best practices.

How does your organisation manage staff identities?

Independent Identity Management: Each service manages identities independently, without integration or synchronisation across systems.

How to determine if this good enough

Your organisation might allow each application or service to store and manage user accounts in its own silo. This can be considered “good enough” if:

  1. Very Small Scale

    • Each service supports only a handful of internal users; overhead of separate sign-ons or user directories is minimal.

  2. Low Risk or Early Pilot

    • No critical data or compliance need to unify identities; you’re still evaluating core cloud or digital services.

  3. No Immediate Need for Central Governance

    • With minimal overlap among applications, the cost or effort of centralising identities doesn’t seem justified yet.

While this approach can initially appear simple, it typically leads to scattered identity practices, poor visibility, and heightened risk (e.g., orphaned accounts). NCSC’s Identity and Access Management guidance and NIST SP 800-53 AC controls suggest unifying identity for consistent security and reduced overhead.

How to do better

Below are rapidly actionable steps to move beyond isolated identity management:

  1. Create a Basic Directory or SSO Pilot

  2. Maintain a Simple User Inventory

    • List out each app’s user base and identify duplicates or potential orphan accounts:
      • Helps to see the scale of the fragmentation problem.

  3. Encourage Unique Credentials

  4. Plan a Gradual Migration

    • Set a short timeline (e.g., 6-12 months) to unify at least a few key services under a single ID provider.

  5. Highlight Quick-Wins

    • If consolidating one or two widely used services to a shared login shows immediate benefits (less support overhead, better logs), use that success to rally internal support.

By implementing a small shared ID approach for new services, maintaining an org-wide user inventory, encouraging unique credentials with basic password hygiene, scheduling partial migrations, and publicising quick results, you steadily reduce the complexity and risk of scattered service-specific identities.

Basic Centralised Identity System: There is a centralised system for identity management, but it’s not fully integrated across all services.

How to determine if this good enough

Your organisation has introduced a centralised identity solution (e.g., Active Directory, Azure AD, or an open-source LDAP), but only some cloud services plug into it. This might be “good enough” if:

  1. Partial Coverage

    • Key or high-risk systems already rely on centralised accounts, while less critical or legacy apps remain separate.

  2. Reduced Complexity

    • The approach cuts down on scattered logins for a majority of staff, although not everyone is unified.

  3. Tolerable Overlap

    • You can manage a few leftover local identity systems, but the overhead is not crushing yet.

To improve further, you can unify or retire the leftover one-off user stores and adopt standards like SAML, OIDC, or SCIM. NCSC identity management best practices and NIST SP 800-63 digital identity guidance typically encourage full integration for better security posture.

How to do better

Below are rapidly actionable steps to further unify your basic centralised identity:

  1. Mandate SSO for New Services

  2. Target Legacy Systems

    • Identify 1-3 high-value legacy applications and plan a short roadmap for migrating them to the central ID store:
      • e.g., rewriting authentication to use SAML or OIDC.

  3. Introduce Periodic Role or Access Reviews

  4. Extend MFA Requirements

  5. Aim for Full Integration by a Set Date

    • e.g., a 12-18 month plan to unify all services, presenting to leadership how this will lower security risk and reduce support costs.

By demanding SSO for new apps, migrating top-priority legacy systems, enabling periodic role reviews, enforcing MFA across the board, and setting a timeline for full integration, you reinforce your centralised identity approach and shrink vulnerabilities from leftover local user stores.

Integrated Identity Management with Some Exceptions: Identities are mostly managed through an integrated system, with a few services still operating independently.

How to determine if this good enough

Your organisation leverages a robust central identity solution for the majority of apps, but certain or older niche services remain separate. It might be “good enough” if:

  1. Dominant Coverage

    • The central ID system handles 80-90% of user accounts, giving broad consistency and security.

  2. Exceptions Are Low-Risk or Temporary

    • The leftover independent systems are less critical or slated for retirement/replacement.

  3. Clear Process for Exceptions

    • Any new service wanting to remain outside central ID must justify the need, preventing random fragmentation.

To move forward, you can retire or integrate these final exceptions and push for short-lived, ephemeral credentials or multi-cloud identity federation. NIST SP 800-53 AC controls and NCSC’s identity approach both stress bridging all apps for consistent security posture.

How to do better

Below are rapidly actionable ways to incorporate the last few outliers:

  1. Establish an “Exception Approval”

    • If a service claims it can’t integrate, mandate a formal sign-off by security or architecture boards:
      • Minimises indefinite exceptions.

  2. Plan Legacy Replacement or Integration

  3. Enhance Monitoring on Exceptions

  4. Regularly Reassess or Sunset Non-Compliant Services

    • If an exception remains beyond a certain period (e.g., 6-12 months), escalate to leadership.
    • This keeps pressure on removing exceptions eventually.

  5. Include Exceptions in Identity Audits

    • Ensure these standalone services aren’t forgotten in user account cleanup or security scanning efforts:
      • e.g., hooking them into an “all-of-org” identity or vulnerability scan at least quarterly.

By requiring official approval for non-integrated systems, scheduling integration projects, monitoring or sunsetting exceptions, and auditing them in the main identity reviews, you unify identity management and ensure consistent security across all cloud services.

Advanced Integrated Identity Management: A comprehensive system manages identities, integrating most services and applications, with efforts to ensure synchronisation and uniformity.

How to determine if this good enough

You have a highly integrated identity solution covering nearly all apps, with consistent provisioning, SSO, and robust security controls like MFA or conditional access. This is likely “good enough” if:

  1. Minimal Manual Overhead

    • Onboarding, offboarding, or role changes propagate automatically to most systems without admin intervention.

  2. High Security & Governance

  3. Frequent Audits & Reviews

    • Identity logs are consolidated, enabling quick detection of anomalies or orphan accounts.

While robust, you could refine ephemeral or short-lived credentials for non-human accounts, integrate cross-department identity, or adopt advanced risk-based authentication. NIST SP 800-63 or 800-53 AC controls highlight the potential for continuous identity posture improvements.

How to do better

Below are rapidly actionable ways to enhance advanced integrated identity management:

  1. Explore Zero-Trust or Risk-Adaptive Auth

  2. Adopt Policy-as-Code for Identity

  3. Enable Fine-Grained Roles and Minimal Privileges

  4. Implement Automated Access Certification

    • Every few months, prompt managers to re-check their team’s privileges:
      • Tools like Azure AD Access Reviews, AWS IAM Access Analyzer, GCP IAM Recommender, or OCI IAM policy checks can highlight unneeded privileges.

  5. Sustain a Culture of Continuous Improvement

By implementing zero-trust or risk-based authentication, adopting identity policy-as-code, refining least privilege roles, automating access certifications, and fostering continuous improvements, you advance from a strong integrated identity environment to a cutting-edge, security-first approach aligned with UK public sector best practices.

Mandatory Single Source of Identity: A single source of identity is mandated for all services, with a strict one-to-one mapping of human to identity, ensuring consistency and security across the organisation.

How to determine if this good enough

At this top maturity level, your organisation enforces one authoritative identity system for every service. All staff have exactly one account, disallowing duplicates or shared credentials. You might consider it “good enough” if:

  1. Complete Uniformity

    • All cloud and on-prem solutions integrate with the same directory/IDP.
    • No leftover local accounts exist.

  2. Strong Accountability

  3. Robust Automation & Onboarding

    • Upon hire or role change, the single identity is updated automatically, provisioning only the needed roles.
    • Offboarding is likewise immediate and consistent.

Even so, you can expand advanced or zero-trust patterns (e.g., ephemeral tokens, risk-based authentication) or multi-department identity federation for cross-government collaboration. NIST SP 800-207 zero trust architecture or NCSC’s advanced identity frameworks might offer further insights.

How to do better

Below are rapidly actionable ways to refine a mandatory single source of identity:

  1. Implement Risk-Adaptive Authentication

  2. Extend Identity to Multi-Cloud

    • If you operate across multiple providers, unify identity definitions so staff seamlessly access AWS, Azure, GCP, or OCI:
      • Possibly referencing external IDPs or cross-cloud SSO integrations.

  3. Incorporate Passwordless Tech

  4. Align with Cross-Government Identity Initiatives

  5. Continuously Review and Audit

By adopting risk-based auth, ensuring multi-cloud identity unification, deploying passwordless approaches, collaborating with cross-government identity programs, and regularly auditing for compliance with the mandatory single source policy, you reinforce a top-tier security stance. This guarantees minimal identity sprawl and maximum accountability in the UK public sector environment.

Keep doing what you’re doing, and consider creating blog posts or making pull requests to this guidance about your advanced single-source identity management success. Sharing practical examples helps other UK public sector organisations move toward robust, consistent identity strategies.

How does your organisation mitigate risks associated with privileged internal threat actors?

Vetting of Privileged Users: All users with privileged access undergo thorough internal vetting (Internal/UKSV) or are vetted according to supplier/contractual requirements.

How to determine if this good enough

Your organisation might ensure privileged users have been vetted by internal or external means (e.g., security clearances or supplier checks). This may be considered “good enough” if:

  1. Rigorous Personnel Vetting

    • Individuals with admin or root-level privileges have the relevant UK security clearance (e.g., BPSS, SC, DV) or supplier equivalent.

  2. No Major Incidents

    • Having not experienced breaches or insider threats, you feel comfortable with existing checks.

  3. Minimal Cloud Scale

    • The environment is small enough that close oversight of a handful of privileged users seems straightforward.

Still, user vetting alone does not fully address the risk of privileged misuse (either malicious or accidental). NCSC’s insider threat guidance and NIST SP 800-53 PS (Personnel Security) controls typically recommend continuous monitoring and robust logging for privileged accounts.

How to do better

Below are rapidly actionable steps to bolster security beyond mere user vetting:

  1. Implement the Principle of Least Privilege

  2. Mandate MFA for Privileged Accounts

  3. Adopt Break-Glass Procedures

    • Provide normal user roles with day-to-day privileges. Escalation to super-user (root/admin) requires justification or time-limited credentials.

  4. Track Changes & Access

  5. Periodic Re-Vetting

By reinforcing least privilege, requiring MFA for admins, introducing break-glass accounts, logging privileged actions immutably, and scheduling re-vetting cycles, you address the limitations of purely one-time user vetting practices.

Audit Logs as a Non-Functional Requirement: Systems are required to maintain audit logs, although these logs lack technical controls for centralisation or comprehensive monitoring.

How to determine if this good enough

In your organisation, each system generates logs to satisfy a broad requirement (“we must have logs”), yet there is no centralised approach or deep analysis. It might be “good enough” if:

  1. Meeting Basic Compliance

    • You have documentation stating logs must exist, fulfilling a minimal compliance or policy demand.

  2. No Frequent Incidents

    • So far, you’ve not needed advanced correlation or instant threat detection from logs.

  3. Limited Complexity

    • Logging requirements are not high or the environment is small, so manual or local checks suffice.

To enhance threat detection and privileged user oversight, you could unify logs centrally and add real-time monitoring. NCSC’s logging guidance and NIST SP 800-92 on log management emphasize the importance of consistent, centralised logging for security and accountability.

How to do better

Below are rapidly actionable steps for robust logging:

  1. Centralise Logs

  2. Implement Basic Retention Policies

  3. Add Tiered Access

    • Ensure only authorised security or audit staff can retrieve log data, particularly sensitive privileged user logs.

  4. Adopt Alerts or Scripting

    • If no advanced SIEM in place, set simple CloudWatch or Monitor alerts for suspicious events:
      • e.g., repeated authentication failures, unusual times for privileged actions.

  5. Plan for Future SIEM

By centralising logs, defining retention policies, restricting log access, employing basic alerts, and charting a path to a future SIEM or advanced monitoring approach, you progress from minimal log compliance to meaningful protective monitoring for privileged accounts.

Local Audit Log Checks During Assessments: Local audit log presence is verified as part of Integrated Technical Health Checks (ITHC) or other pre-launch processes, but routine monitoring may be absent.

How to determine if this good enough

Your organisation ensures that each new system or release passes an ITHC or security check verifying logs exist, but ongoing monitoring or correlation might not happen. This could be “good enough” if:

  1. Meeting Basic Security Gate

    • You confirm audit logs exist before go-live, mitigating total absence of logging.

  2. High Manual Effort

    • Teams may do point-in-time checks or random sampling of logs without continuous oversight.

  3. Some Minimal Risk Tolerance

    • If no major security incidents forced you to need real-time log analysis, you remain comfortable with the status quo.

Yet, post-launch, missing continuous log analysis can hamper early threat detection or wrongdoing by privileged users. NCSC protective monitoring guidance and NIST SP 800-53 AU controls highlight the importance of daily or real-time monitoring, not just checks at go-live.

How to do better

Below are rapidly actionable steps to enhance local audit log checks:

  1. Introduce Scheduled Log Reviews

    • e.g., once a month or quarter, verify logs remain present, complete, and show no anomalies:
      • Provide a short checklist or script for consistent checks.

  2. Adopt a Central Logging Approach

  3. Establish an Alerting Mechanism

    • Set triggers for suspicious events:
      • repeated privileged commands, attempts to disable logging, or high-volume data exfil events.

  4. Retest Periodically

  5. Involve Security/Operations in Reviews

    • Encourage cross-team peer reviews, so security staff or ops can weigh in on log completeness or retention policies.

By scheduling routine log reviews, centralising logs or employing a SIEM, establishing real-time alerts, retesting logs beyond initial go-live, and collaborating with security teams on checks, you elevate from one-time assessments to ongoing protective monitoring.

Centralised, Immutable Audit Logs with Automated Monitoring: Immutable system audit logs are centrally stored. Their integrity is continuously assured, and the auditing process is automated. Log retention is defined and enforced automatically.

How to determine if this good enough

Your organisation ensures all logs flow into a tamper-proof or WORM (write-once, read-many) storage with automated processes for retention and monitoring. This may be “good enough” if:

  1. Complete Coverage

    • Every system relevant to security or privileged actions ships logs to a central store with read-only or append-only policies.

  2. Daily or Real-Time Analysis

    • Automated scanners or scripts detect anomalies (e.g., unauthorised attempts, suspicious off-hours usage).

  3. Confidence in Legal/Evidential Status

Still, you might expand cross-department correlation (e.g., combining logs from multiple agencies), adopt advanced threat detection (AI/ML), or align with zero-trust. Continuous improvement helps keep pace with evolving insider threats.

How to do better

Below are rapidly actionable ways to enhance a centralised, immutable audit logging approach:

  1. Incorporate a SIEM or Security Analytics

  2. Define Tiered Log Retention

    • Some logs might only need short retention, while privileged user logs or financial transaction logs might need multi-year retention, referencing departmental policies or NCSC recommended durations.

  3. Implement Role-Based Log Access

  4. Add Instant Alerts for High-Risk Actions

  5. Cross-department Collaboration

By coupling an advanced SIEM with defined retention tiers, enforcing role-based log access, setting real-time alerts for critical events, and collaborating beyond your department, you push your centralised, immutable logging approach to best-in-class standards aligned with public sector needs.

How to determine if this good enough

At this highest maturity level, your organisation not only has robust logging but also runs frequent legal and forensic validations. This approach is typically “good enough” if:

  1. Thorough Testing & Legal Assurance

  2. Confidence in Potential Criminal Cases

    • If insider misuse occurs, logs can stand up in court, verifying chain-of-custody and authenticity.

  3. Mature Culture & Processes

    • Teams are trained to handle forensic data, ensuring minimal disruption or tampering when collecting logs for review.

You may further refine by adopting next-generation forensics tools, cross-department collaborations, or advanced capabilities for HPC/AI-based anomaly detection. NIST SP 800-86 for digital forensics processes or NCSC advanced forensic readiness guidance highlight continuous improvement potential.

How to do better

Below are rapidly actionable suggestions to deepen advanced log audits and legal compliance:

  1. Formalise Forensic Readiness

  2. Simulate Real-World Insider Incidents

    • Conduct tabletop exercises or “red team” scenarios focusing on a privileged user gone rogue:
      • confirm the logs indeed catch suspicious actions and remain legally defensible.

  3. Adopt Chain-of-Custody Tools

  4. Engage with Legal/HR for Pre-Agreed Procedures

    • Ensure a consistent approach to handle suspected insider cases, clarifying roles for HR, security, legal, and management:
      • Minimises delays or confusion during investigations.

  5. Leverage Cross-department Insights

By refining your forensic readiness policy, running insider threat simulations, implementing chain-of-custody measures, coordinating with legal/HR teams, and exchanging insights cross-department, you maximise the readiness and legal defensibility of your logs, ensuring robust protection against privileged internal threats in the UK public sector environment.

Keep doing what you’re doing, and consider blogging or creating pull requests to share these advanced approaches for safeguarding logs, verifying legal readiness, and mitigating privileged insider threats. Such knowledge helps strengthen collective security practices across UK public sector organisations.

How does your organisation monitor and manage security within its software supply chain?

Unmanaged Dependencies: Dependencies are not formally managed, installed ad-hoc as needed, and updated periodically without tracking versions or full dependency trees, such as using apt or yum to install packages without a manifest file that can operate as an SBOM.

How to determine if this good enough

Your organisation or team may install open-source or third-party packages in an unstructured, manual manner, without consistent dependency manifests or version locks. This might be “good enough” if:

  1. Limited or Non-Critical Software

    • You only run small, low-risk applications where you’re comfortable with less stringent controls.

  2. Short-Lived, Experimental Projects

    • Minimal or proof-of-concept code that’s not used in production, so supply chain compromise would have little impact.

  3. No Strong Compliance Requirements

    • There’s no immediate demand to generate or maintain an SBOM, or to comply with stricter public sector security mandates.

However, ignoring structured dependency management often leads to vulnerabilities, unknown or out-of-date libraries, and risk. NCSC’s supply chain security guidance and NIST SP 800-161 on supply chain risk management recommend tracking dependencies to mitigate malicious or outdated code infiltration.

How to do better

Below are rapidly actionable steps to handle unmanaged dependencies more safely:

  1. Adopt Basic Package Manifests

    • Even if you install packages with apt, create a minimal list of versions used. For language-based repos (Node, Python, etc.), commit package.json / Pipfile or equivalent:
      • Minimises drift and ensures consistent builds.

  2. Begin Generating Simple SBOM

  3. Enable Automatic or Regular Patch Checks

  4. Document a Basic Update Policy

  5. Plan an Overhaul to Managed Dependencies

    • In the next 3-6 months, decide on a standard approach for dependencies:
      • e.g., using Node’s package-lock.json, Python’s requirements.txt, or Docker images pinned to specific versions.

By adopting minimal package manifests, generating basic SBOM data, automating patch checks, documenting an update policy, and planning a transition toward managed dependencies, you lay the groundwork for a more secure, transparent software supply chain.

Basic Dependency Management with Ad-Hoc Monitoring: All dependencies are set at project initiation and updated during major releases or in response to significant advisories. Some teams use tools to monitor supply chain security in an ad-hoc manner, scanning dependency manifests with updates aligning with project releases.

How to determine if this good enough

Your organisation employs some form of version locking or pinned dependencies, typically updating them at major releases or if a high-profile vulnerability arises. This might be “good enough” if:

  1. Moderate Project Complexity

    • Projects can survive months without routine dependency updates, posing little risk.

  2. Partial Security Consciousness

    • Team leads scan dependencies manually or with open-source scanners but only in reaction to CVE announcements.

  3. Limited DevSecOps

    • Minimal continuous integration or automated scanning, relying on manual processes at release cycles.

Though better than unmanaged approaches, you might further automate scanning, adopt continuous patching, or integrate advanced DevSecOps. NCSC’s supply chain best practices and NIST SP 800-161 underscore proactive and more frequent checks.

How to do better

Below are rapidly actionable ways to strengthen basic dependency management:

  1. Automate Regular Dependency Scans

  2. Define a Scheduled Update Policy

  3. Maintain SBOM or Lock Files

  4. Enable Alerting for Known Vulnerabilities

  5. Document Emergency Patching

    • Formalise an approach for urgent CVE patching outside major releases.
    • Minimises ad-hoc panic when a high severity bug appears.

By automating scans, scheduling regular update windows, maintaining SBOM or lock files, setting up vulnerability alerts, and establishing a well-defined emergency patch process, you move from ad-hoc monitoring to a more structured, frequent approach that better secures the software supply chain.

Proactive Remediation Across Repositories: All repositories are actively monitored, with automated remediation steps. Updates are systematically applied, aligning with project release schedules.

How to determine if this good enough

Your organisation has begun actively scanning code repositories, triggering automated dependency updates or PRs when new vulnerabilities appear. This might be considered “good enough” if:

  1. Frequent Dependency Updates

    • Teams integrate fresh library versions on a weekly or sprint basis, not just big releases.

  2. Automated Patches or Merge Requests

    • Tools generate PRs automatically for security fixes, and developers review or test them quickly.

  3. Wider Organisational Awareness

    • Alerts or dashboards highlight vulnerabilities in each project, ensuring consistent coverage across the enterprise.

You could further improve by employing advanced triage (prioritising fixes by severity or usage context), adopting container image scanning, or establishing a centralised SOC for supply chain threats. NCSC’s protective monitoring or NIST SP 800-161 supply chain risk management approach outlines more advanced strategies.

How to do better

Below are rapidly actionable ways to strengthen proactive repository remediation:

  1. Introduce Risk Scoring or Context

    • Distinguish vulnerabilities that truly impact your code path from those that are unreferenced dependencies:
      • e.g., using advanced scanning tools like Snyk, Sonatype, or vendor-based solutions.

  2. Adopt Container and OS Package Scanning

  3. Refine Automated Testing

  4. Define an SLA for Fixes

  5. Document & Track Exceptions

    • If a patch is delayed (e.g., due to breakage risk), keep a formal record of why and a timeline for resolution:
      • Minimises the chance of indefinite deferral of serious issues.

By introducing vulnerability risk scoring, scanning container/OS packages, enhancing test automation for new patches, setting fix SLAs, and controlling deferrals, you significantly improve the proactive repository-level remediation approach across your entire software estate.

Centralised Monitoring with Context-Aware Triage: A centralised Security Operations Center (SOC) maintains an overview of all repositories, coordinating high-severity issue remediation. The system also triages issues based on dependency usage context, focusing remediation efforts on critical issues.

How to determine if this good enough

Your organisation’s SOC or security team has a single pane of glass for code repositories, assessing discovered vulnerabilities in context (e.g., usage path, data sensitivity). You might see it “good enough” if:

  1. Robust Overviews

    • The SOC sees each project’s open vulnerabilities, ensuring none slip through cracks.

  2. Contextual Prioritisation

    • Vulnerabilities are triaged by severity and usage context (are dependencies actually loaded at runtime?).

  3. Coordinated Response

    • The SOC, dev leads, and ops teams collaborate on remediation tasks; no major backlog or confusion over ownership.

You can further refine by adopting advanced threat intel feeds, deeper container or HPC scanning, or linking to enterprise risk management. NCSC’s advice on a protective monitoring approach and NIST SP 800-171 for protecting CUI in non-federal systems might inform future expansions.

How to do better

Below are rapidly actionable ways to refine centralised, context-aware triage:

  1. Add Real-Time Threat Intelligence

  2. Automate Contextual Analysis

    • Tools that parse call graphs or code references to see if a vulnerable function is actually invoked:
      • Minimises false positives and patch churn.

  3. Collaborate with Dev Teams

    • If a patch might break production, the SOC can coordinate safe rollout or canary testing to confirm stability before mandatory updates.

  4. Measure & Publish Remediation Metrics

    • e.g., average time to fix a critical CVE or high severity vulnerability.
    • Encourages healthy competition and accountability across teams.

  5. Align with Overall Risk Registers

By integrating real-time threat intel, employing contextual code usage analysis, collaborating with dev for safe patch rollouts, tracking remediation metrics, and linking to broader risk management, you elevate centralised monitoring to a dynamic, strategic posture in addressing supply chain security.

Advanced, Integrated Security Management: This approach combines centralised monitoring, risk management, and context-aware triage, with a focus on minimising false positives and ensuring focused, effective remediation across the organisation’s software supply chain.

How to determine if this good enough

At this highest maturity level, your organisation unifies proactive scanning, advanced threat intel, context-based triage, and real-time analytics to handle supply chain security. You might consider it “good enough” if:

  1. Minimal Noise, High Impact

    • Automated processes accurately prioritise genuine threats, with few wasted cycles on false positives.

  2. Strategic Alignment

  3. Cross-Organisational Culture

    • DevOps, security, and product leads collaborate seamlessly, ensuring supply chain checks are integral to release processes.

Still, you might adopt zero trust or HPC/AI scanning, cross-government code sharing, or advanced developer training as next steps. NIST SP 800-161 on supply chain risk management and NCSC advanced DevSecOps patterns suggest iterative expansions of scanning and collaboration.

How to do better

Below are rapidly actionable ways to refine advanced, integrated supply chain security:

  1. Implement Automated Policy-as-Code

  2. Extend SBOM Generation & Validation

  3. Adopt Multi-Factor Scanning

  4. Coordinate with Supplier/Partner Security

  5. Drive a Security-First Culture

By implementing policy-as-code in your pipelines, strengthening SBOM usage, blending multiple scanning techniques, managing upstream vendor security, and fostering a security-first ethos, you sustain a cutting-edge supply chain security environment—ensuring minimal risk, maximum compliance, and rapid threat response across UK public sector software development.

How does your organisation monitor and manage threats, vulnerabilities, and misconfigurations?

No Vulnerability Management: It is not clear to a member of the public how they can report vulnerabilities in your systems.

How to determine if this good enough

Your organisation may not offer any channel or official statement on how external security researchers or even the general public can report potential security flaws. It might be seen as “good enough” if:

  1. Very Limited External Exposure

    • The services you run are not publicly accessible or have little interaction with external users.

  2. Low Risk Tolerance

    • You have minimal data or no major known threat vectors, so you assume public disclosure might be rarely needed.

  3. Short-Term or Pilot

    • You’re in an early stage and have not formalised public-facing vulnerability reporting.

However, failing to provide a clear disclosure route can lead to undisclosed or zero-day vulnerabilities persisting in your systems. NCSC’s vulnerability disclosure guidelines and NIST SP 800-53 SI (System and Information Integrity) controls emphasize the importance of structured vulnerability reporting to quickly remediate discovered issues.

How to do better

Below are rapidly actionable steps to implement basic vulnerability reporting:

  1. Publish a Simple Disclosure Policy

  2. Set Up a Dedicated Email or Form

    • Provide a clear email (like security@yourdomain.gov.uk) or secure submission form:
      • Minimises confusion about who to contact.

  3. Respond with a Standard Acknowledgement

    • Even an automated template that thanks the researcher and notes you’ll follow up within X days fosters trust.

  4. Engage Leadership

    • Brief senior management that ignoring external reports can lead to missed critical vulnerabilities.

  5. Plan a Gradual Evolution

    • Over the next 6-12 months, consider joining a responsible disclosure platform or adopting a bug bounty approach for larger-scale feedback.

By defining a minimal disclosure policy, setting up a dedicated channel, creating an acknowledgment workflow, involving leadership awareness, and planning for future expansions, you shift from no vulnerability management to a more transparent and open approach that encourages safe vulnerability reporting.

Open Policy or Participation in Responsible Disclosure Platforms: Clear instructions for responsible vulnerability disclosure are published, with a commitment to prompt response upon receiving reports, you may also have active participation in well-known responsible disclosure platforms to facilitate external reporting of vulnerabilities.

How to determine if this good enough

Your organisation provides a public vulnerability disclosure policy or is listed on a responsible disclosure platform (e.g., HackerOne, Bugcrowd). It might be “good enough” if:

  1. Good Public Communication

    • External researchers or citizens know precisely how to submit a vulnerability, and you respond within a stated timeframe.

  2. Moderate Volunteer Testing

    • You handle moderate volumes of reported issues, typically from well-intentioned testers.

  3. Decent Internal Triage

However, you could enhance your approach with automated scanning and proactive threat detection. NIST SP 800-53 or 800-161 supply chain risk guidelines often advise balancing external reports with continuous internal or automated checks.

How to do better

Below are rapidly actionable ways to evolve beyond a standard disclosure policy:

  1. Link Policy with Internal Remediation SLAs

    • For example, “critical vulnerabilities responded to within 24 hours, resolved or mitigated within 7 days,” to ensure a consistent process.

  2. Integrate with DevSecOps

  3. Offer Coordinated Vulnerability Disclosure Rewards

    • If feasible, small gestures (like public thanks or acknowledgement) or bug bounty tokens encourage more thorough testing from external researchers.

  4. Publish Summary of Findings

    • Periodically share anonymised or high-level results of vulnerability disclosures, illustrating how quickly you resolved them.
    • Builds trust with citizens or partner agencies.

  5. Combine with Automated Tools

By defining clear internal SLAs, integrating vulnerability disclosures into dev workflows, offering small acknowledgments or bounties, releasing summary fix timelines, and coupling with continuous scanning tools, you can both refine external disclosure processes and ensure robust internal vulnerability management.

Automated Scanning and Regular Assessments: Implementation of automated tools for scanning vulnerabilities and misconfigurations, combined with regular security assessments.

How to determine if this good enough

Your organisation invests in standard security scanning (e.g., SAST, DAST, container scans) as part of CI/CD or separate regular testing, plus periodic manual assessments. This is likely “good enough” if:

  1. Continuous Improvement

    • Regular scans detect new vulnerabilities promptly, feeding them into backlog or release cycles.

  2. Routine Audits

  3. Clear Remediation Path

    • Once discovered, vulnerabilities are assigned owners and typically resolved in a reasonable timeframe.

You might refine the process by adding advanced threat hunting, zero trust, or cross-department threat intelligence sharing. NIST SP 800-53 CA controls and NCSC’s protective monitoring approach recommend proactive threat monitoring in addition to scanning.

How to do better

Below are rapidly actionable ways to enhance scanning and regular assessments:

  1. Expand to Multi-Layer Scans

  2. Adopt Real-Time or Daily Scans

    • If feasible, move from monthly/quarterly to daily or per-commit scanning in your CI/CD pipeline.
    • Early detection fosters quicker fixes.

  3. Integrate with SIEM

  4. Prioritise with Risk Scoring

  5. Publish Shared “Security Scorecards”

    • Departments or teams see summary risk/vulnerability data. Encourages knowledge sharing and a culture of continuous improvement.

By broadening scanning layers, shifting to more frequent scans, integrating results in a SIEM, risk-scoring discovered issues, and creating departmental security scorecards, you refine a robust automated scanning regimen that swiftly addresses vulnerabilities.

Proactive Threat Hunting and Incident Response: Proactive threat hunting practices are in place. Incident response teams rapidly address identified threats and vulnerabilities, with some degree of automation in responses.

How to determine if this good enough

Your organisation has a dedicated security function or SOC actively hunting for suspicious activity, not just waiting for automated scanners. It might be “good enough” if:

  1. Threat Intelligence Feeds

    • The SOC or security leads incorporate intel on new attack vectors or high-profile exploits, scanning your environment proactively.

  2. Swift Incident Response

    • When a threat is found, dedicated teams quickly isolate and remediate within defined SLAs.

  3. Partial Automation

    • Some standard or low-complexity threats are auto-contained (e.g., blocking known malicious IPs, quarantining compromised containers).

You could extend capabilities with advanced forensics readiness, red/purple team exercises, or more granular zero-trust microsegmentation. NCSC’s incident management guidance and NIST SP 800-61 Computer Security Incident Handling Guide encourage continuous threat hunting expansions.

How to do better

Below are rapidly actionable methods to refine proactive threat hunting and incident response:

  1. Adopt Purple Teaming

    • Combine red team (offensive) and blue team (defensive) exercises periodically to test detection and response workflows.
    • e.g., referencing NCSC red teaming best practices.

  2. Enable Automated Quarantine

  3. Add Forensic Readiness

  4. Integrate Cross-Government Threat Intel

  5. Expand Zero-Trust Microsegmentation

By introducing purple teaming, automating quarantine procedures, ensuring forensic readiness, collaborating on threat intel across agencies, and adopting zero-trust microsegmentation, you deepen your proactive stance and expedite incident responses.

Comprehensive Security Operations with Red/Purple Teams: Utilisation of red teams (offensive security) and purple teams (combined offensive and defensive) for a full-spectrum security assessment. An empowered Security Operations Center (SOC) conducts at least annual and major change-based IT Health Checks (ITHC). Analysts prioritise and coordinate remediation of high-severity issues, with many mitigation actions automated and event-triggered.

How to determine if this good enough

At this top maturity level, your organisation invests in continuous offensive testing and advanced SOC operations. It’s likely “good enough” if:

  1. Extensive Validation

    • Regular (annual or more frequent) red team exercises and major release-based ITHCs confirm robust security posture.

  2. Sophisticated SOC

    • The SOC actively hunts threats, triages vulnerabilities, and automates mitigations for known patterns.

  3. Organisational Priority

    • Leadership supports ongoing security testing budgets, responding promptly to critical findings.

Still, you might refine multi-cloud threat detection, adopt advanced AI-based threat analysis, or integrate cross-public-sector threat sharing. NCSC’s advanced operational resilience guidelines and NIST SP 800-137 for continuous monitoring encourage iterative expansions.

How to do better

Below are rapidly actionable ways to optimise comprehensive security operations:

  1. Incorporate HPC/AI Security

  2. Include Third-Party Supply Chain

  3. Automate Cross-Cloud Security

  4. Public-Sector Collaboration

  5. Continuously Evaluate Zero-Trust

By adopting HPC/AI-targeted checks, incorporating suppliers in red team exercises, unifying multi-cloud threat intelligence, collaborating across public sector units, and reinforcing zero-trust initiatives, you further enhance your holistic security operations. This ensures comprehensive, proactive defense against sophisticated threats and misconfigurations in the UK public sector context.

Keep doing what you’re doing, and consider blogging or opening pull requests to share your advanced security operations approaches. This knowledge supports other UK public sector organisations in achieving robust threat/vulnerability management and protective monitoring aligned with NCSC, NIST, and GOV.UK best practices.

What approach does your organisation take towards network architecture for security?

Traditional Network Perimeter Security: Security relies primarily on network-level controls like IP-based allow-lists and firewall rules to create a secure perimeter around hosted data and applications.

How to determine if this good enough

Your organisation might rely heavily on firewall rules, IP allow-lists, or a perimeter-based model (e.g., on-premises network controls or perimeter appliances) to secure data and apps. This might be “good enough” if:

  1. Limited External Exposure

    • Only a few services are exposed to the internet, while most remain behind a well-managed firewall.

  2. Legacy Infrastructure

    • The environment or relevant compliance demands a dedicated network perimeter approach, with limited capacity to adopt more modern identity-based methods.

  3. Strict On-Prem or Single-Cloud Approach

    • If everything is co-located behind on-prem or one cloud’s network layer, perimeter rules might reduce external threats.

Yet perimeter security alone can fail if an attacker bypasses your firewall or uses compromised credentials internally. NCSC’s zero-trust principles and NIST SP 800-207 Zero Trust Architecture both encourage focusing on identity-based checks rather than relying solely on network boundaries.

How to do better

Below are rapidly actionable steps to strengthen or evolve from perimeter-only security:

  1. Introduce MFA for Privileged Access

  2. Implement Least-Privilege IAM

  3. Segment Networks Internally

  4. Enable TLS Everywhere

  5. Plan for Identity-Based Security

    • Over the next 6-12 months, pilot a small zero-trust or identity-centric approach for a less critical app, paving the way to reduce dependence on perimeter rules.

By enforcing multi-factor authentication, introducing least-privilege IAM, segmenting networks internally, ensuring end-to-end TLS, and planning a shift toward identity-based models, you move beyond the risks of purely perimeter-centric security.

Network Security with Basic Identity Verification: The traditional network-based security perimeter is supplemented with mechanisms to verify user identity within the context of access requests.

How to determine if this good enough

Your organisation still maintains a perimeter firewall, but user identity checks (e.g., login with unique credentials) are enforced when accessing apps behind it. It might be “good enough” if:

  1. Mixed Legacy and Modern Systems

    • Some older apps demand perimeter-level protection, but you do require user logins or limited authentication steps for critical apps.

  2. Basic Zero-Trust Awareness

    • Recognising that IP-based controls alone are insufficient, you at least require unique logins for each service.

  3. Minimal Threat or Complexity

    • You’ve had no incidents from insider threats or compromised internal network segments.

Though an improvement over pure perimeter reliance, deeper identity-based checks can help. NCSC’s zero-trust approach and NIST SP 800-207 guidelines promote validating each request’s user or device identity, not just pre-checking them at the perimeter.

How to do better

Below are rapidly actionable ways to extend identity verification:

  1. Enforce MFA for All Users

  2. Increase Granularity of Access Controls

  3. Adopt SSO

  4. Enable Auditing & Logging

  5. Consider Device Trust or Conditional Access

    • If feasible, require verified device posture (up-to-date OS, security agent running) before granting app access.

By mandating MFA for all, refining role-based or service-level access, introducing SSO, logging all user actions, and optionally checking device security posture, you significantly reduce reliance on a single perimeter gate.

Enhanced Identity Verification: Security includes verification of both user and service identities in the context of requests, augmenting the network-based security perimeter.

How to determine if this good enough

You verify not just the user’s identity but also ensure the service or system making the request is authenticated. This indicates a move towards more modern, partial zero-trust concepts. It might be “good enough” if:

  1. Service Identities

    • Non-human accounts also need secure tokens or certificates, so you know which microservice or job is calling your APIs.

  2. User + Service Auth

    • Each request includes user identity (or claims) plus the service’s verified identity.

  3. Reduced Attack Surface

    • Even if someone penetrates your perimeter, they need valid service credentials or ephemeral tokens to pivot or call internal APIs.

To progress further, you might adopt advanced mutual TLS, ephemeral identity tokens, or partial zero-trust microsegmentation. NCSC’s zero-trust approach and NIST SP 800-207 Zero Trust Architecture both advise deeper trust evaluations for each request.

How to do better

Below are rapidly actionable ways to strengthen user+service identity verification:

  1. Use mTLS or Short-Lived Tokens

  2. Adopt Policy-as-Code

  3. Enforce Request-Level Authorisation

  4. Implement JIT Privileges

    • For especially sensitive or admin tasks, require ephemeral or just-in-time escalation tokens (with a short lifetime).

  5. Log & Analyze Service-to-Service Interactions

By implementing mTLS or ephemeral tokens for user+service identity, deploying policy-as-code, requiring request-level authorisation, enabling JIT privileges for critical tasks, and thoroughly logging microservice communications, you move closer to a robust zero-trust framework within a partially perimeter-based model.

Partial Shift to Identity-Centric Security: In some areas, the network-based security perimeter is replaced by robust identity verification mechanisms for users and services, reducing the reliance on VPNs for secure access.

How to determine if this good enough

Your organisation has started phasing out VPN or perimeter-based approaches, preferring direct connections where each request is authenticated and authorised at the identity level. It’s likely “good enough” if:

  1. Mixed Environments

    • Some apps still use older network-based rules, but new services rely on modern identity or SSO for access.

  2. Reduction in Attack Surface

    • No blanket VPN that grants wide network access—users or microservices authenticate to each resource directly.

  3. Increasing Zero Trust

    • You see initial success in adopting zero-trust patterns for some apps, but not fully universal yet.

To advance, you might unify all apps under identity-based controls, incorporate advanced device posture checks, or adopt full microsegmentation. NCSC’s zero-trust guidance and NIST SP 800-207 Zero Trust Architecture frameworks can guide further expansions.

How to do better

Below are rapidly actionable ways to deepen identity-centric security:

  1. Retire or Restrict VPN

  2. Embed Device Trust

    • Combine user identity with device compliance checks:
      • e.g., [Azure AD Conditional Access with device compliance, Google BeyondCorp device posture, AWS or OCI solutions integrated with MDM] for advanced zero-trust.

  3. Embrace Microsegmentation

  4. Establish Single Sign-On for All

  5. Continuously Train Staff

By methodically retiring or limiting VPN usage, integrating device posture checks, employing microsegmentation, standardising single sign-on for all apps, and training staff on the identity-centric model, you further reduce perimeter dependence and approach a more robust zero-trust posture.

No Reliance on Network Perimeter or VPN: The organisation has moved away from a network-based security perimeter. Access control is centered around individual devices and users, requiring strong attestations for trust establishment.

How to determine if this good enough

At this final maturity level, your organisation’s security is fully identity- and device-centric—no blanket perimeter or VPN. You might consider it “good enough” if:

  1. Zero-Trust Realisation

  2. Full Cloud or Hybrid Environment

    • You’ve adapted all systems to identity-based access, no backdoor VPN routes or firewall exceptions.

  3. Streamlined Access

    • Staff easily connect from anywhere, but each request must prove who they are and what device they’re on before gaining resources.

Even so, consider advanced HPC/AI zero-trust expansions, cross-department identity federation, or deeper attribute-based access control. Continuous iteration remains beneficial to match evolving threats, as recommended by NCSC and NIST guidance.

How to do better

Below are rapidly actionable ways to sustain no-perimeter, identity-based security:

  1. Refine Device & User Risk Scoring

  2. Enforce Continuous Authentication

  3. Extend Zero-Trust to Microservices

  4. Use Policy-as-Code

  5. Collaborate & Share

    • As a leading zero-trust example, share your experiences or case studies with other public sector bodies, referencing cross-government events or guidance from GDS / NCSC communities.

By deploying advanced device risk scoring, introducing continuous re-auth, expanding zero trust to microservices, employing policy-as-code for dynamic guardrails, and collaborating across the public sector, you refine your environment as a modern, identity-centric security pioneer, fully detached from traditional network perimeters and VPN reliance.

Keep doing what you’re doing, and consider writing up your experiences or opening pull requests to share your zero-trust or identity-centric security transformations. This knowledge benefits other UK public sector organisations striving to reduce reliance on network perimeters and adopt robust, identity-first security models.

What is your organisation's approach to implementing 2FA/MFA for securing access?

How to determine if this good enough

Your organisation may advise staff to enable 2FA (two-factor) or MFA (multi-factor) on their accounts, but it’s left to personal choice or departmental preference. This might be “good enough” if:

  1. Minimal Risk Appetite

    • You have low-value, non-sensitive services, so the impact of compromised accounts is relatively small.

  2. Testing or Early Rollout

    • You’re in a pilot phase before formalising a universal requirement.

  3. No High-Stakes Obligations

    • You don’t face stringent regulatory demands or public sector security mandates.

However, purely optional MFA typically leads to inconsistent adoption. NCSC’s multi-factor authentication guidance and NIST SP 800-63B Identity Assurance Level recommendations advise requiring MFA for all or at least privileged accounts to significantly reduce credential-based breaches.

How to do better

Below are rapidly actionable steps to move from an “encouraged” MFA model to a consistent approach:

  1. Identify Privileged Accounts First

  2. Educate Staff on Risks

  3. Incentivise Voluntary Adoption

    • Recognise teams or individuals who enable MFA (e.g., shout-outs or small accolades).
    • Encourages cultural acceptance before a final mandate.

  4. Publish a Simple Internal FAQ

  5. Plan a Timeline for Mandatory MFA

    • Over 3–6 months, aim to require MFA for at least all staff accessing sensitive services.

By prioritising MFA for privileged users, educating staff on credential compromise scenarios, incentivising early adoption, providing user-friendly setup instructions, and scheduling a near-future MFA mandate, you evolve from optional guidance to real protective measures.

Mandated but Inconsistently Enforced: 2FA/MFA is a requirement for all services and users, but enforcement is inconsistent and may have gaps.

How to determine if this good enough

Your organisation has a policy stating all staff “must” enable MFA. However, actual compliance might vary—some services allow bypass, or certain users remain on single-factor. This can be “good enough” if:

  1. Broad Organisational Recognition

    • Everyone knows MFA is required, reducing the risk from total single-factor usage.

  2. Partial Gains

    • Many staff and services do indeed use MFA, reducing the chance of mass credential compromise.

  3. Resource Constraints

    • Full enforcement or zero exceptions aren’t yet achieved due to time, legacy systems, or user objections.

Though better than optional MFA, exceptions or non-enforcement create holes. NCSC’s MFA best practices and NIST SP 800-63B (AAL2+) advise systematically enforcing multi-factor to effectively protect user credentials.

How to do better

Below are rapidly actionable methods to close the enforcement gap:

  1. Enable Enforcement in Cloud IAM

  2. Monitor for Noncompliance

  3. Apply a Hard Deadline

    • Communicate a date beyond which single-factor logins will be revoked, referencing official departmental or local policy.

  4. Offer Support & Tools

  5. Handle Legacy Systems

By enabling built-in forced MFA, monitoring compliance, communicating a strict cutoff date, supplying alternative authenticators, and bridging older systems with SSO or proxy solutions, you systematically remove any gaps that allow single-factor access.

Uniform Enforcement with Some Exceptions: 2FA/MFA is uniformly enforced across all services and users, with only a few exceptions based on specific use cases or risk assessments.

How to determine if this good enough

Your organisation has successfully mandated MFA for nearly every scenario, though a small number of systems or roles may not align due to technical constraints or a specific risk-based exemption. This is likely “good enough” if:

  1. High MFA Coverage

    • Over 90% of your users and services require multi-factor login, drastically minimising account compromise risk.

  2. Well-Documented Exceptions

    • Each exception is risk-assessed and typically short-term. The organisation knows precisely which systems lack enforced MFA.

  3. Strong Culture & Processes

    • Staff generally accept MFA as standard, and you rarely experience pushback or confusion.

At this stage, you can refine advanced or stronger factors (e.g., hardware tokens, FIDO2) for privileged accounts, or adopt risk-based step-up authentication. NCSC multi-factor recommendations and NIST SP 800-63B “Auth Assurance Levels” advise continuing improvements.

How to do better

Below are rapidly actionable ways to remove or mitigate the last few exceptions:

  1. Document a Sunset Plan for Exceptions

    • If a system can’t integrate MFA now, define a target date or solution path (like an MFA-proxy or upgrade).
    • Minimises indefinite exceptions.

  2. Risk-Base or Step-Up

  3. Consider Device-Focused Security

  4. Combine with Identity-Centric Security

  5. Review & Renew

    • Periodically re-check each exception’s rationale—some may no longer be valid as technology or policies evolve.

By planning for the eventual elimination of exceptions, deploying step-up authentication for sensitive tasks, ensuring device posture checks for minimal-risk scenarios, integrating identity-based zero-trust, and reviewing exceptions regularly, you further strengthen your universal MFA adoption.

Prohibition of Vulnerable 2FA/MFA Methods: Stronger 2FA/MFA methods are enforced, explicitly excluding forms vulnerable to attacks like SIM swapping (e.g., SMS/phone-based methods).

How to determine if this good enough

Your organisation refuses to allow SMS-based or similarly weak MFA. Instead, you use TOTP apps, hardware tokens, or other resilient factors. This might be “good enough” if:

  1. High-Security Requirements

    • Handling sensitive citizen data or critical infrastructure, so you need robust protection from phishing and SIM-swap attacks.

  2. Firm Policy

    • You publish a stance that phone-based authentication is disallowed, ensuring staff adopt recommended alternatives.

  3. Consistent Implementation

    • Everyone’s using TOTP, FIDO2 tokens, or other strong factors. Rarely do exceptions exist.

However, you might still refine device posture checks, adopt hardware-based tokens for privileged roles, or integrate continuous authentication for maximum security. NCSC’s guidance on phishing-resistant MFA and NIST SP 800-63B AAL3 recommendations highlight advanced factors beyond TOTP.

How to do better

Below are rapidly actionable enhancements:

  1. Adopt FIDO2 or Hardware Security Keys

  2. Set Up Backup Mechanisms

  3. Integrate Risk-Based Policies

  4. Consider Device Certificates

    • For some use cases, device-based certificates or mTLS can supplement user factors, further preventing compromised endpoints from impersonation.

  5. Regularly Revisit Factor Security

By introducing hardware-based MFA, ensuring robust fallback processes, applying risk-based authentication for suspicious attempts, deploying device certs, and staying alert to newly discovered factor vulnerabilities, you push your “no weak MFA” stance to a sophisticated, security-first environment.

Stringent 2FA/MFA with Hardware Key Management: Only services supporting robust 2FA/MFA are used. Hardware-based MFA keys are centrally managed and distributed, ensuring high-security standards for authentication.

How to determine if this good enough

At this pinnacle, your organisation requires hardware-based tokens (e.g., FIDO2, YubiKeys, or similar) for all staff, forbidding weaker factors like SMS or even TOTP. This is typically “good enough” if:

  1. Full Hardware Token Adoption

    • Everyone uses hardware keys for login, including privileged or admin accounts.

  2. Central Key Lifecycle Management

  3. High Assurance

You could still refine ephemeral or risk-adaptive auth, integrate zero-trust posture checks, and implement cross-department hardware token bridging. Continuous iteration ensures alignment with future security advances. NCSC’s advanced multi-factor recommendations or vendor-based hardware token solutions might help expand coverage.

How to do better

Below are rapidly actionable ways to optimise hardware-based MFA:

  1. Embrace Risk-Based Authentication

  2. Implement Zero-Trust & Microsegmentation

  3. Maintain Inventory & Lifecycle

    • Automate key distribution, revocation, or replacement. If a staff member loses a token, the system quickly blocks it.
    • e.g., a central asset management or HR-driven approach ensuring no leftover active tokens for departed staff.

  4. Test Against Realistic Threats

  5. Plan for Cross-department Interoperability

By coupling hardware tokens with adaptive risk checks, adopting zero-trust microsegmentation for each request, carefully managing the entire token lifecycle, running targeted red team tests, and exploring cross-department usage, you elevate an already stringent hardware-based MFA approach to a seamlessly integrated, high-security ecosystem suitable for sensitive UK public sector operations.

Keep doing what you’re doing, and consider sharing your experiences or opening pull requests to this guidance. Others in the UK public sector can learn from how you enforce robust MFA standards, whether using FIDO2 hardware keys, advanced risk-based checks, or zero-trust patterns.

What is your organisation's approach to managing privileged access?

Ad-Hoc Management by Administrators: Privileged credentials are managed on an ad-hoc basis by individual system administrators, without standardised processes.

How to determine if this good enough

Your organisation may let each system admin handle privileged credentials independently, storing them in personal files or spreadsheets. This might be acceptable if:

  1. Small-Scale or Legacy Systems

    • You have few privileged accounts and limited complexity, and potential downsides of ad-hoc management haven’t yet materialised.

  2. Short-Term or Pilot

    • You’re in a transitional stage, planning to adopt better solutions soon but not there yet.

  3. No Pressing Compliance Requirements

    • Strict audits or public sector mandates for privileged account management haven’t been triggered.

However, ad-hoc methods often risk unauthorised usage, inconsistent rotation, and difficulty tracking who accessed what. NCSC’s privileged account security guidance and NIST SP 800-53 AC-6 (least privilege) emphasise stricter control over privileged credentials.

How to do better

Below are rapidly actionable steps to move beyond ad-hoc privileged credential management:

  1. Create a Basic Privileged Access Policy

  2. Mandate Individual Admin Accounts

    • Eliminate shared “admin” user logins. Each privileged user gets a unique account so you can track actions.

  3. Introduce MFA for Admins

  4. Document & Track Privileged Roles

    • Keep a minimal register or spreadsheet listing all privileged accounts, systems they access, and assigned owners:
      • Helps see if too many administrators exist.

  5. Schedule Transition to Vaulting

By creating a short privileged access policy, enforcing unique admin accounts with MFA, documenting roles, and preparing for a vault-based solution, you significantly reduce the risk of ad-hoc mismanagement and insider threats.

Centralised Controls with Basic Vaulting: Technology controls are in place for centralised management, including initial password and key vaulting, integrated logs, and policy-based activities.

How to determine if this good enough

Your organisation implements a vaulting solution (e.g., a password manager or secrets manager) that securely stores privileged credentials, with usage logs or basic policy checks. This might be “good enough” if:

  1. Reduced Credential Sprawl

    • No more random spreadsheets or personal note files; vault usage is mandatory for storing admin credentials.

  2. Initial Logging & Policy

    • Access to vault entries is logged, and policy controls (like who can retrieve which credential) exist.

  3. Improved Accountability

    • Audit logs show which admin took which credential, though real-time or advanced analytics may be limited.

To enhance further, you can adopt ephemeral credentials, just-in-time privilege grants, or integrate automatic rotation. NCSC’s privileged access management guidance and NIST SP 800-63B AAL2+ usage for admin accounts suggest deeper automation and advanced threat detection.

How to do better

Below are rapidly actionable steps to refine centralised vaulting:

  1. Enable Automatic Credential Rotation

  2. Integrate with CI/CD

    • If dev pipelines need privileged credentials (e.g., for deployment), fetch them from the vault at runtime, never storing them in code or config:

  3. Automate Access Reviews

  4. Adopt Fine-Grained Access Policies

  5. Add Multi-Factor for Vault Access

By rotating credentials automatically, integrating vault secrets into CI/CD, conducting periodic access reviews, refining vault access policies, and enforcing MFA for vault retrieval, you build a stronger, more secure foundation for privileged credentials management.

Structured Identity Administration with OTPs: Identity administration controls and processes are established for managing privileged access, including the use of one-time passwords (OTPs).

How to determine if this good enough

In this scenario, your organisation has formal processes: new privileged accounts require an approval workflow, privileges are tracked, and one-time passwords or tokens might be used to access certain sensitive credentials or sessions. It may be “good enough” if:

  1. Managed Lifecycle

    • You have explicit procedures for provisioning, rotating, and revoking privileged accounts.

  2. OTP for Sensitive Operations

    • For high-risk tasks (e.g., root or “god-mode” usage), a user must supply a fresh OTP from the vault or via a token generator.

  3. Reduced Risk

    • Mandatory approvals and short-lived passcodes curb the chance of stale or misused privileged credentials.

Still, you might consider advanced measures like ephemeral role assumption, context-based or zero-trust policies, or real-time threat detection. NCSC’s privileged user management best practices and NIST SP 800-53 AC-6 advanced usage outline continuing improvements.

How to do better

Below are rapidly actionable ways to strengthen identity administration and OTP usage:

  1. Integrate OTP into Break-Glass Procedures

  2. Use Security Keys for Admin Access

  3. Automate Logging & Alerts

  4. Schedule Regular Privileged Access Reviews

  5. Expand OTP to Non-Human Accounts

    • Where feasible, short-lived tokens for services or automation tasks too, fostering ephemeral credentials.

By embedding OTP steps in break-glass procedures, adopting hardware tokens for admins, enabling automated logs/alerts, reviewing privileged roles frequently, and using ephemeral tokens for services as well, you build a more rigorous privileged access model with robust checks.

Automated Risk-Based Access Control: Privileged access is managed through automated, risk-based workflows and controls. This includes consistent monitoring across cloud platforms.

How to determine if this good enough

Your organisation has advanced systems that dynamically adjust privileged user access based on real-time signals (e.g., user context, device posture, time of day), with logging across multiple clouds. It’s likely “good enough” if:

  1. Flexible, Policy-Driven Access

    • Certain tasks require elevated privileges only when risk or context is validated (e.g., location-based or device checks).

  2. Unified Multi-Cloud Oversight

    • You can see all privileged accounts for AWS, Azure, GCP, OCI in a single pane, highlighting anomalies.

  3. Prompt Mitigation & Revocation

    • If an account shows unusual behavior, the system can auto-limit privileges or alert security leads in near real-time.

You could refine it by adopting zero-trust microsegmentation for each privileged action, or real-time AI threat detection. NCSC’s zero trust approach and NIST SP 800-207 Zero Trust Architecture often encourage continuous verification for highest-value accounts.

How to do better

Below are rapidly actionable ways to elevate automated, risk-based privileged access:

  1. Incorporate Threat Intelligence

  2. Tie Access to Device Posture

  3. Implement Granular Observability

  4. Automate Just-in-Time (JIT) Access

  5. Regular Security Drills

By combining threat intelligence, verifying device posture, enabling granular session-level logging, adopting just-in-time privileges, and running regular security exercises, you further refine risk-based controls for privileged access across all cloud platforms.

Context-Aware Just-in-Time Privileges: Access is granted on a just-in-time basis, using contextual factors to determine necessity (e.g., time-based access for critical tasks). Real-time alerting is in place for all activity, with mandatory wash-ups that require Senior leadership present, prioritisation given to automating and preventing further need.

How to determine if this good enough

At this highest maturity level, your organisation dynamically grants privileged access based on real-time context (time window, location, device posture, or manager approval) and logs all actions. Senior leadership is involved in after-action reviews for critical escalations. This is typically “good enough” if:

  1. Comprehensive Zero-Trust

    • Privileged roles exist only if requested and verified in real-time, with ephemeral credentials.

  2. Senior Leadership Accountability

    • The mandatory wash-up sessions ensure no suspicious or repeated escalations go unexamined, reinforcing a security-focused culture.

  3. Automation Minimises Need

Though advanced, you may refine HPC/AI roles under ephemeral policies, integrate multi-department identity bridging, or further embed AI-based anomaly detection. Continual iteration aligns with future public sector security demands.

How to do better

Below are rapidly actionable ways to optimise context-aware just-in-time privileges:

  1. Deeper Risk-Based Logic

  2. Enforce Micro-Segmentation

    • Combine ephemeral privileges with strict micro-segmentation: each resource requires a separate ephemeral token:
      • Minimises lateral movement if any one credential is compromised.

  3. Incorporate Real-Time Forensic Tools

  4. Enable AI/ML Anomaly Detection

  5. Regular Multi-Stakeholder Drills

By enhancing risk-based logic in JIT access, pairing ephemeral privileges with micro-segmentation, adopting real-time forensic checks, integrating AI-based anomaly detection, and practicing multi-stakeholder drills, you perfect a context-aware just-in-time privileged access model that secures the most sensitive operations in the UK public sector context.

Keep doing what you’re doing, and consider blogging or creating pull requests to share your experiences in implementing advanced privileged access systems with just-in-time context-based controls. Such knowledge benefits other UK public sector bodies aiming to secure administrative actions under a zero-trust, ephemeral access paradigm.

What measures are in place in your organisation to mitigate the risk of data breaches, including exfiltration, corruption, deletion, and non-availability?

Manual Data Access Classification: Data access is primarily managed through manual classification, with minimal automation or centralised control.

How to determine if this good enough

Your organisation may rely on ad-hoc or manual processes to classify and secure data (e.g., staff deciding on classification levels individually, using guidelines but no enforcement tooling). This can be acceptable if:

  1. Small or Low-Risk Datasets

    • You handle minimal or non-sensitive data, so the impact of a breach is low.

  2. Limited Organisational Complexity

    • A few staff or single department handle data security manually, and no major compliance demands exist yet.

  3. Short-Term/Pilot State

    • You’re in early experimentation with cloud, planning better controls soon.

However, manual classification often leads to inconsistent labeling, insufficient logging, and potential data mishandling. NCSC’s data security guidance and NIST SP 800-53 SC (System and Communications Protection) controls advise more structured data classification and automated policy enforcement.

How to do better

Below are rapidly actionable steps to move beyond manual classification:

  1. Adopt a Simple Data Classification Scheme

  2. Introduce Basic Tooling

  3. Require Access Controls

  4. Document a Minimal Process

    • A short policy clarifying how staff label data, who can reclassify, and how they request access changes:
      • Minimises confusion or inconsistent labeling.

  5. Plan for Automated Classification

By introducing a simple classification scheme, adopting minimal tooling for labeling, ensuring basic least-privilege access, documenting a short classification process, and preparing for automated solutions, you create a more structured approach to data security than purely manual methods.

Centralised Policies and Controls: A centralised set of policies and controls is in place to prevent unauthorised data access, forming the core of the data security strategy.

How to determine if this good enough

Your organisation has a recognised policy framework (e.g., data classification policy, access controls) and uses central configuration to handle data security, typically at least partially automated. This might be “good enough” if:

  1. Consistent Application

    • Most teams adhere to defined policies, ensuring a baseline of uniform data protection.

  2. Reduced Complexity

  3. Moderate Maturity

    • You can see a consistent approach to user or service access across departmental data repositories.

You could enhance these controls by adding real-time monitoring, automation for labeling, or advanced data flow analysis. NCSC’s zero trust approach and NIST SP 800-171 for protecting CUI can guide expansions to more granular or continuous data security.

How to do better

Below are rapidly actionable ways to strengthen centralised data security policies:

  1. Implement Automated Policy Enforcement

  2. Add Tiered Access

  3. Consolidate Data Stores

  4. Define a Data Lifecycle

  5. Monitor for Policy Deviations

By automating policy enforcement, requiring tiered access for sensitive data, consolidating data stores, clarifying data lifecycle, and monitoring for policy anomalies, you refine your centralised data security approach, ensuring consistent coverage and minimal manual drift.

Policies with Limited Monitoring: In addition to centralised policies and controls, limited monitoring for data exfiltration is conducted to identify potential breaches.

How to determine if this good enough

Your organisation enforces data protection policies but only partially monitors for suspicious activity (e.g., some DLP or logging solutions in place). It might be “good enough” if:

  1. Basic DLP or Anomaly Detection

    • You log file transfer or download activity from key systems, though coverage might not be universal.

  2. Minimal Incidents

    • You rarely see large-scale data leaks, so partial monitoring hasn’t caused major issues.

  3. Structured but Incomplete

    • Policies exist for classification, encryption, and access, but continuous or real-time exfiltration detection is partial.

You can strengthen by adopting more advanced DLP solutions, real-time anomaly detection, and integrated threat intelligence. NCSC’s protective monitoring approach and NIST SP 800-53 SI controls emphasize continuous detection and response to suspicious data movements.

How to do better

Below are rapidly actionable ways to expand limited monitoring:

  1. Adopt or Expand DLP Tools

  2. Integrate SIEM for Correlation

  3. Add Real-Time Alerts

    • If a user downloads an unusually large amount of data or from unusual IPs, trigger immediate SOC or security team notifications.

  4. Include Lateral Movement Checks

  5. Regular Drills and Tests

    • Simulate data exfil attempts or insider threat to test if your limited monitoring indeed picks up suspicious events.

By leveraging or expanding DLP solutions, correlating logs in a SIEM, implementing real-time anomaly alerts, detecting lateral movement, and running exfiltration drills, you enhance your approach from partial monitoring to more comprehensive oversight of data movements.

Comprehensive Controls with Automated Detection: Preventative, detective, and corrective controls are implemented. Anomaly detection and correction are automated using a range of platforms and tools, providing a more robust defense.

How to determine if this good enough

Your organisation employs layered controls (encryption, classification, role-based access, DLP) plus automated anomaly detection systems. This approach might be “good enough” if:

  1. Cross-Platform Coverage

    • Data in AWS, Azure, GCP, or on-premises is consistently monitored, with uniform detection rules.

  2. Immediate Alerts & Automated Responses

    • If suspicious exfil or corruption is detected, the system can contain the user or action in near real-time.

  3. Mature Security Culture

    • Staff know that unusual data activity triggers alerts, so they practice good data handling.

Further evolution might include advanced zero trust for each data request, HPC/AI-specific DLP, or integrated cross-department data threat intelligence. NCSC operational resilience guidance and NIST SP 800-137 continuous monitoring frameworks highlight ongoing improvements in automation and analytics.

How to do better

Below are rapidly actionable methods to reinforce automated detection:

  1. Risk-Scored Alerts

  2. Automated Quarantine & Blocking

  3. Integrate Threat Intelligence

    • Use external feeds or cross-government intel to see if certain IP addresses or tactics target your data assets.

  4. Regularly Update Detection Rules

    • Threat patterns evolve; schedule monthly or quarterly rule reviews to incorporate the latest TTPs (tactics, techniques, and procedures) used by adversaries.

  5. Drill Data Restoration

By adding risk-scored alerts, automatically quarantining suspicious activity, incorporating threat intelligence, periodically updating detection rules, and verifying backups or DR for data restoration, you create a highly adaptive system that promptly detects and mitigates data breach attempts.

Fully Automated Security and Proactive Monitoring: Advanced, fully automated controls and anomaly detection systems are in place. This includes proactive monitoring, regular access reviews, and continuous auditing to ensure data security and compliance.

How to determine if this good enough

At this top maturity level, your organisation’s data breach prevention strategy is fully integrated, with real-time automated responses and proactive scanning. It’s typically “good enough” if:

  1. Continuous Visibility & Reaction

  2. Frequent Access & Security Reviews

    • Privileged or sensitive data access is automatically logged, regularly audited for minimal or suspicious usage.

  3. Seamless Multi-Cloud or Hybrid

    • You track data across AWS, Azure, GCP, on-prem systems, or container/Kubernetes platforms with uniform policies.

Even so, you might refine advanced AI-based analytics, adopt cross-department supply chain correlation, or evolve HPC data security. NCSC’s zero trust posture or NIST SP 800-207 zero trust architecture can guide further improvements.

How to do better

Below are rapidly actionable ways to refine fully automated, proactive data security:

  1. Leverage AI/ML for Data Anomalies

  2. Adopt Policy-as-Code

  3. Expand Zero-Trust Microsegmentation

    • Ensure each request for data is validated at the identity, device posture, and context level, even inside your environment:

  4. Cross-Government Data Sharing

  5. Regular “Chaos” or Stress Tests

By employing AI-driven anomaly detection, embedding policy-as-code for data security, adopting zero-trust microsegmentation, collaborating on cross-government data controls, and running robust chaos or stress tests, you sustain a cutting-edge, proactive data protection approach suitable for the evolving demands of UK public sector operations.

Keep doing what you’re doing, and consider blogging about or opening pull requests to share how you maintain or improve your data breach mitigation strategies. Your experiences support other UK public sector organisations, reinforcing best practices under NCSC, NIST, and GOV.UK guidance.

Technology

How are technology selections made for new projects within your organisation?

Ad-Hoc and Independent Selections: Each project independently selects technologies, leading to a diverse and often incompatible technology estate.

How to determine if this good enough

Your organisation may let project teams pick any tech stack or tool they prefer, resulting in minimal standardisation. This can be considered “good enough” if:

  1. Small or Isolated Projects

    • Few cross-dependencies exist; each project runs mostly independently without needing to integrate or share solutions.

  2. Low Risk & Early Stage

    • You’re in an experimental or startup-like phase, testing different tools before formalising a standard.

  3. No Centralised Governance Requirements

    • There isn’t (yet) a policy from senior leadership or compliance bodies demanding consistent technology choices.

However, purely ad-hoc selections often lead to higher maintenance costs, learning curves, and integration challenges. NCSC’s cloud and digital guidance and NIST enterprise architecture best practices encourage balancing project freedom with broader organisational consistency and security.

How to do better

Below are rapidly actionable ways to move away from fully independent, unaligned technology decisions:

  1. Start a Basic Tech Catalog

    • Document each major technology used across projects, referencing at least version, licensing, security posture:
      • Helps discover overlaps or common solutions already in use.

  2. Create a Minimal Governance Policy

  3. Encourage Knowledge Sharing

    • Run short “tech share” sessions, where teams present why they picked certain tools:
      • fosters cross-project alignment.

  4. Identify Quick-Win Common Tools

    • E.g., centralised logging or container orchestration solutions (AWS ECS/EKS, Azure AKS, GCP GKE, OCI OKE) standardising at least some operational aspects.

  5. Plan for a Tech Radar or Steering Group

    • Over the next 3–6 months, propose forming a small cross-departmental group or technology radar process to guide future selections.

By documenting existing tools, drafting minimal governance, facilitating knowledge exchange, pinpointing shared solutions, and preparing a technology steering approach, you mitigate fragmentation while still preserving some project autonomy.

Uniform Technology Mandate: Technology choices are highly regulated, with a uniform, organisation-wide technology stack that all projects must adhere to.

How to determine if this good enough

Your organisation has a strict policy (e.g., “All apps must use Java + Oracle DB” or a locked stack). It can be considered “good enough” if:

  1. Stable & Predictable

    • The environment is stable, and forced uniformity hasn’t hindered project innovation or changed business needs drastically.

  2. Meets Regulatory Compliance

  3. Sufficient for Current Workloads

    • No major impetus from staff or leadership to adopt new frameworks or advanced cloud services.

Nevertheless, overly rigid mandates can stifle innovation, leading to shadow IT or suboptimal solutions. GOV.UK’s service manual on agile and iterative approaches often advises balancing standardisation with flexibility for user needs.

How to do better

Below are rapidly actionable ways to refine a uniform tech mandate:

  1. Allow Exceptions via a Lightweight Process

  2. Maintain a Living “Approved List”

    • Encourage periodic updates to the mandated stack, adding modern solutions (like container orchestration or microservice frameworks) that align with cost and security best practices:

  3. Pilot Innovations

  4. Implement Regular Tech Reviews

    • e.g., every 6–12 months, a board or steering group reviews the mandated stack in light of feedback or new GDS or NCSC recommendations.

  5. Combine with Security & Cost Insights

    • Show how uniform solutions reduce risk and expense, reassuring teams that standardisation benefits them while still enabling progress in areas like containerisation or DevSecOps.

By allowing exceptions via a straightforward process, regularly updating the approved tech list, sponsoring pilot projects, scheduling periodic reviews, and highlighting cost/security gains, you preserve the benefits of uniform technology while avoiding stagnation or shadow IT.

Guided by Outdated Resources: A technology radar and some documented patterns exist, but they are outdated and not widely regarded as useful or relevant.

How to determine if this good enough

Your organisation made an effort to produce a technology radar or pattern library, but it’s now stale or incomplete. Teams may ignore it, preferring to research on their own. It might be “good enough” if:

  1. Past Good Intentions

    • The existing radar or patterns once offered value, but no one has updated them in 1-2 years.

  2. Low Current Impact

    • Projects have found alternative references, so the outdated resources do minimal harm.

  3. No High-Level Mandates

    • Leadership or GDS/NCSC have not mandated an up-to-date approach yet.

Still, stale patterns or radars can lead to confusion about which tools are recommended or disapproved. NCSC’s guidance on choosing secure technology solutions and NIST’s enterprise architecture best practices emphasize regularly refreshed references for modern security features.

How to do better

Below are rapidly actionable ways to revitalise or replace outdated resources:

  1. Initiate a Quick Radar Refresh

  2. Introduce a Living “Tech Patterns” Wiki

    • Encourage teams to add their experiences or recommended patterns, so the resource remains collaborative and dynamic:
      • e.g., referencing [Confluence, GitHub Wiki, or internal SharePoint with version control].

  3. Schedule Semi-Annual Reviews

  4. Gather Feedback

    • Ask project teams what patterns they rely on or find missing. Include new technologies that have proven valuable:
      • fosters a sense of collective ownership.

  5. Use Real Examples

    • Populate the updated patterns with success stories from internal projects that solved real user needs.

By quickly refreshing the tech radar, establishing a living wiki, scheduling periodic updates, gathering project feedback, and focusing on real success stories, you transform outdated references into a relevant, frequently consulted guide that shapes better technology decisions.

Current and Maintained Guidance: A regularly updated technology radar, along with current documentation and patterns, covers a wide range of use cases and is actively used for guidance.

How to determine if this good enough

Your organisation invests in a living, frequently updated set of technology choices or recommended patterns, which teams genuinely consult before starting projects. This can be “good enough” if:

  1. Broad Adoption

    • Most dev/ops teams refer to the radar or patterns and find them beneficial.

  2. Timely Updates

    • Items are regularly revised in response to new cloud services, NCSC security alerts, or new GDS guidelines.

  3. Consistent Security & Cost

    • The recommended solutions reduce redundant spend and ensure up-to-date security features.

To push further, you might incorporate a community-driven pipeline for continuous improvement or collaborate with cross-public sector bodies on shared patterns. NIST enterprise architecture best practices or NCSC supply chain guidelines can help integrate security aspects more deeply.

How to do better

Below are rapidly actionable ways to enhance current, well-used guidance:

  1. Introduce a “Feedback Loop”

  2. Add Security & Cost Criteria

  3. Practice “Sunsetting”

    • If a technology on the radar is outdated or replaced, mark it for deprecation with a recommended timeline:
      • Minimises legacy tech usage.

  4. Conduct Regular Showcases

    • Let teams demo how they used a recommended pattern or overcame a challenge.
    • Encourages synergy and real adoption.

  5. Cross-Gov Collaboration

By enhancing feedback channels, adding security/cost insights to each item, marking deprecated technologies, hosting showcases, and collaborating across agencies, you keep the guidance fresh, relevant, and beneficial for new project tech decisions.

Collaborative and Evolving Ecosystem: Regular show-and-tell sessions and collaboration with existing teams are encouraged. There’s a strong emphasis on reusing and extending existing solutions, alongside rewarding innovation and experimentation.

How to determine if this good enough

At this top maturity level, your organisation not only maintains up-to-date patterns or a tech radar, but also fosters a culture of continuous improvement and knowledge sharing. This is typically “good enough” if:

  1. Inherent Collaboration

    • Teams frequently discuss or exchange solutions, referencing real success or lessons to guide new projects.

  2. Focus on Reuse

    • If an app or microservice solves a common problem, others can adopt or adapt it, reducing duplication.

  3. Encouragement of New Ideas

Nevertheless, you can refine advanced cross-government collaboration, embed HPC or AI solutions, or adopt multi-cloud synergy. NIST SP 800-160 for software engineering considerations and NCSC’s supply chain and DevSecOps guidance might help expand.

How to do better

Below are rapidly actionable ways to strengthen a collaborative, evolving tech ecosystem:

  1. Establish a Formal Inner-Source Model

    • Encourage code sharing or libraries across departments, referencing open-source practices but within the public sector context:

  2. Encourage Pairing or Multi-Dept Projects

  3. Recognise Innovators

    • Publicly highlight staff who introduce successful new frameworks or cost-saving architecture patterns:
      • fosters a healthy “improvement” culture.

  4. Adopt Cross-department Show-and-Tell

  5. Integrate Feedback into Tech Radar

    • Each time a new solution is proven, update the radar or patterns promptly:
      • ensuring the living doc truly represents real usage and best practice.

By establishing an inner-source approach, supporting short cross-team collaborations, celebrating innovators, connecting with other public sector bodies for knowledge sharing, and consistently updating patterns or the tech radar, you continuously evolve an energetic ecosystem that fosters reuse, innovation, and high-quality technology decisions.

Keep doing what you’re doing, and consider writing some blog posts or opening pull requests to share how your collaborative, evolving tech environment benefits your UK public sector organisation. This helps others adopt or improve similar patterns and fosters a culture of open innovation across government.

What characterises the majority of your current technology stack?

Monolithic Applications with Wide Technology Stack: The predominant architecture is monolithic, with applications deployed as single, indivisible units encompassing a wide range of technologies.

How to determine if this good enough

Your organisation may bundle most functionalities (e.g., front-end, back-end, database access) into a single codebase. This can be considered “good enough” if:

  1. Limited Project Scale

    • You have only a few apps or these monoliths aren’t facing rapid feature changes that necessitate frequent deployments.

  2. Stability Over Innovation

    • The environment is stable, with minimal demands for agile or continuous deployment.

  3. No Pressing Modernisation Requirements

    • No immediate need from leadership or compliance frameworks for microservices, containerisation, or advanced DevSecOps.

However, monoliths often slow new feature rollout and hamper scaling. NCSC’s DevSecOps guidance and NIST SP 800-160 systems engineering best practices typically advise considering modular approaches to handle evolving user needs and security updates more flexibly.

How to do better

Below are rapidly actionable steps to transition from a monolithic approach:

  1. Identify Natural Component Boundaries

    • E.g., separate a large monolith into core modules (user authentication, reporting, payment processing).
    • Provide early scoping for partial decomposition.

  2. Adopt Container or VM Packaging

  3. Refactor Shared Libraries

  4. Automate Basic CI/CD

  5. Plan a Phased Decomposition

By identifying component boundaries, packaging the monolith for simpler deployments, refactoring shared libraries, automating CI/CD, and scheduling partial decomposition, you reduce friction and set a path toward more modular solutions.

Modular but Not Independently Deployable: Applications are broken down into modules, offering greater development flexibility, yet these modules are not deployable as independent components.

How to determine if this good enough

Your application is conceptually modular—teams write separate modules or libraries—but the final deployment still merges everything into a single artifact or container. It can be considered “good enough” if:

  1. Moderate Complexity

    • The system’s complexity is contained enough that simultaneous deployment of modules is tolerable.

  2. Basic Reuse

    • Code modules are reused across the solution, even if they deploy together.

  3. No Continuous Deployment Pressure

    • You can handle monolithic-ish releases with scheduled downtime or limited user impact.

Though better than a single massive codebase, you might miss the benefits of shipping each module independently. NCSC DevOps best practices and NIST SP 800-204 microservices architecture guidance suggest modular architectures with independent deployment can accelerate security fixes and scaling.

How to do better

Below are rapidly actionable ways to shift modules from concept to independent deployment:

  1. Introduce Containerisation at Module-Level

  2. Provide Separate Build Pipelines

  3. Adopt an API or Messaging Boundary

  4. Test and Deploy Modules Independently

    • Even if they remain part of a bigger system, trial partial independent deploys:
      • e.g., can you update a single library or microservice without redeploying everything?

  5. Demonstrate Gains

    • Show leadership how incremental module updates reduce downtime or accelerate security patching:
      • Encourages buy-in for further decoupling.

By containerising modules, setting up separate build pipelines, enforcing clear module boundaries, individually deploying or updating modules, and showcasing tangible benefits, you progress toward a fully independent deployment pipeline that capitalises on modularity.

Modularised and Individually Deployable Components: Applications are structured into self-contained, individually deployable components. However, significant interdependencies add complexity to testing.

How to determine if this good enough

You have multiple microservices or modules each packaged and deployable on its own. However, there may be strong coupling (e.g., version sync or data schema dependencies). It can be “good enough” if:

  1. Significant Gains Over Monolith

    • You can release some parts separately, reducing the scope of each deployment risk.

  2. Partial Testing Complexity

    • Integrations require orchestrated end-to-end tests or mocking, but you still benefit from incremental updates.

  3. Mature DevOps Practices

    • Each component has a pipeline, though simultaneous releases across many components might pose a challenge.

Nevertheless, heavy interdependencies hamper the full advantage of modular architectures. NCSC zero trust or microsegmentation approaches and NIST microservices best practices advocate further decoupling or contract-based testing to reduce friction.

How to do better

Below are rapidly actionable ways to handle interdependencies in individually deployable components:

  1. Introduce Contract Testing

  2. Automate Consumer-Driven Testing

    • Consumers of a service define expected inputs/outputs; the service must pass these for each release.
    • Minimises “integration hell.”

  3. Adopt Semantic Versioning

  4. Publish a Dependency Matrix

  5. Enforce Feature Flags

By introducing contract or consumer-driven testing, adopting semantic versioning, publishing a compatibility matrix, and employing feature flags to manage cross-component rollouts, you reduce interdependency friction and safely leverage your modular architecture.

Mostly Independent Deployment with Some Monoliths: While most application components are independently deployable and testable, a few core system components still rely on a monolithic architecture.

How to determine if this good enough

Your organisation has successfully modularised most services, yet some legacy or core systems remain monolithic due to complexity or historical constraints. It may be “good enough” if:

  1. Limited Legacy Scope

    • Only a small portion of the overall estate is monolithic, so the negative impacts are contained.

  2. Proven Stability

    • The remaining monolith(s) might be stable, with minimal changes needed, reducing the urgency of refactoring.

  3. Mature DevOps for Modern Parts

    • You enjoy the benefits of microservices for most new features or cloud expansions.

To fully benefit from independent deployments, you might eventually replace or further decompose those monoliths. NCSC’s approach to legacy modernisation or NIST SP 800-160 engineering guidelines can help plan that transition.

How to do better

Below are rapidly actionable ways to address the leftover monolithic elements:

  1. Identify High-Impact Subsystem to Extract

  2. Establish Clear Migration Plan

    • e.g., define a 12–24 month roadmap with incremental steps or re-platforming on containers:
      • Minimises big-bang rewrites.

  3. Enhance DevOps for Monolith

    • Even if it remains monolithic for a while, ensure robust CI/CD, container packaging, automated tests, referencing NCSC DevSecOps guidance.

  4. Limit New Features in Legacy

    • Encourage new capabilities or major enhancements in microservices around the edges, gradually reducing the monolith’s importance.

  5. Highlight ROI & Risk

    • Present management with cost of leaving the monolith vs. benefits of further decomposition (faster releases, easier security fixes).

By selecting high-impact subsystems for extraction, creating a phased migration plan, applying DevOps best practices to the existing monolith, steering new features away from legacy, and continuously communicating the ROI of decomposition, you inch closer to a fully modular environment.

Fully Component-Based Modular Architecture: The technology stack consistently utilises a component-based modular approach. All components are independently testable and deployable, free from monolithic stack dependencies.

How to determine if this good enough

At this pinnacle, your organisation’s technology stack is entirely modular or microservices-based, each component testable and deployable on its own. It might be “good enough” if:

  1. Highly Agile & Scalable

    • Teams release features or bug fixes individually, mitigating risk and accelerating time-to-value.

  2. Strong DevOps Maturity

  3. Minimal Coupling

    • Interdependencies are managed via robust APIs or messaging, enabling each component to evolve with minimal friction.

Even so, you can refine HPC/AI or domain-specific modules, adopt advanced zero-trust gating, or unify cross-organisational microservices. NCSC’s guidance on microservices security and NIST SP 800-204 microservices frameworks encourage continuous improvements.

How to do better

Below are rapidly actionable ways to optimise a fully component-based approach:

  1. Enhance Observability & Tracing

  2. Apply Zero-Trust for Service Communication

  3. Adopt or Refine Service Mesh

  4. Continuous Architecture Review

    • With so many components, schedule architecture retros or periodic design reviews ensuring no sprawl or duplication arises.

  5. Collaborate Across Departments or Agencies

By enhancing distributed tracing, adopting zero-trust service communications, exploring or refining a service mesh, scheduling architecture reviews, and collaborating with other government entities, you maintain a top-tier, fully component-based environment that remains agile, secure, and efficient in meeting public sector demands.

Keep doing what you’re doing, and consider sharing or blogging about your experience with modular architectures. Contributing pull requests to this guidance or other best-practice repositories helps UK public sector organisations adopt similarly progressive strategies for building and maintaining cloud and on-premises systems.