Serverless Architecture for Regulated Enterprises. What Changes When You Stop Managing the Server

Serverless architecture can remove a significant amount of infrastructure management from your teams. It does not remove architectural responsibility, operational risk or regulatory accountability.

Moving a workload to serverless changes who provisions, patches, scales and operates parts of the underlying technology. Your organisation must still understand the data, dependencies, security controls, resilience requirements and third parties supporting the business service.

The question is not simply whether serverless is faster, cheaper or more modern. It is whether transferring more infrastructure responsibility to a cloud provider creates the right balance of value, risk and control for that particular workload.

For regulated organisations, the decision depends on whether the workload suits the model, which responsibilities transfer to the provider, which remain with the organisation and whether the resulting service can be secured, monitored, recovered and explained from end to end.

• If you need the fundamentals first, our guide explains serverless computing, how it works and where it fits. Here, we focus on the additional architectural, operational and governance decisions facing regulated and highly governed enterprises.

What serverless architecture changes

Serverless architecture is a cloud model in which the provider manages much of the infrastructure and platform needed to execute application code or deliver managed services.

The servers have not disappeared. Your team no longer provisions or manages them directly.

Depending on the service, the provider may take responsibility for allocating capacity, maintaining the underlying infrastructure, applying platform updates and scaling execution environments. Serverless applications are commonly built from functions and managed cloud services connected through events, APIs and messaging.

The National Cyber Security Centre’s guidance on the cloud shared responsibility model places serverless towards the more managed end of cloud computing. It also makes clear that the division of security responsibilities depends on the service model and how the provider has implemented it.

With traditional infrastructure, your organisation may manage operating systems, patching, capacity and runtime configuration, as well as significant parts of the resilience model. Serverless transfers more of that underlying platform operation to the provider.

Your organisation’s attention therefore shifts towards:

• workload and application design
• data protection and governance
• identities and permissions
• service configuration
• dependencies and integrations
• logging and end-to-end monitoring
• resilience and recovery
• provider and concentration risk
• the business outcomes the workload supports

This can be a valuable trade-off, provided the responsibilities that have transferred and those that remain with your organisation are clearly understood.

Why serverless is different in a regulated enterprise

Serverless can simplify delivery by transferring more infrastructure operation to a cloud provider. In a regulated enterprise, however, it must also be possible to demonstrate that the resulting service remains secure, resilient and appropriately governed.

Infrastructure operation can be outsourced. Accountability for the business service cannot.

The FCA’s guidance on outsourcing and operational resilience makes this clear for financial services. Depending on the arrangement and the firm’s regulatory perimeter, cloud services may form part of a material outsourcing or material third-party arrangement. The firm remains responsible for meeting its regulatory obligations and maintaining the resilience of the important business services that depend on those services.

Financial services provides one of the clearest UK examples, but the architectural principle applies more broadly wherever organisations operate under formal security, resilience, data or accountability requirements.

This does not make serverless unsuitable for regulated workloads. Trusted cloud providers may be better equipped to perform some infrastructure and security activities consistently at scale. The NCSC recommends delegating appropriate security responsibilities to trusted cloud providers and notes that more managed services can make certain security responsibilities easier to meet.

The organisation must still design, configure and govern the service correctly. It must also retain sufficient evidence to demonstrate that the relevant controls are working.

A regulated architecture therefore needs to establish:

• what data is processed, where it is stored and whether it crosses jurisdictions
• how data is encrypted and who controls the encryption keys
• which identities can invoke, configure or administer each service
• which managed services and external providers the workload depends on
• how activity is logged, protected, retained and audited
• how security incidents are detected, investigated and reported
• what happens when a component, region or provider service fails
• how the business service is recovered and whether recovery has been tested
• which dependencies could fail together
• what would be required to move, replace or exit the service
• who remains accountable for the business service and its associated risks

Serverless architecture. What you can hand to the cloud provider and what you cannot

The attraction of serverless is that the provider operates more of the underlying technical stack. This reduces the infrastructure your teams must provision, patch and maintain, but it does not create a clean handover of responsibility.

A simplified division looks like this:

The precise division varies by service. A function platform, serverless database, managed queue and identity service each create a different responsibility model. Responsibility can also vary according to the provider, service tier, configuration and region selected.

The NCSC’s shared responsibility guidance makes the broader point clear. The responsibilities delegated to the provider depend on the service model and how it is implemented. The customer remains responsible for choosing, configuring and using the service appropriately.

Serverless architecture benefits when the workload fits

Serverless can provide genuine advantages for regulated enterprises when the workload suits the model.

These can include:

• less infrastructure to provision, patch and maintain
• automatic scaling within defined platform limits
• strong support for event-driven processing
• reduced idle capacity for intermittent workloads
• faster access to managed cloud capabilities
• less operational effort devoted to underlying infrastructure

There may also be a security benefit. A hyperscale provider can manage infrastructure security, patching, monitoring and platform operations consistently across large environments. The NCSC notes that cloud-native services, including serverless, can make some security responsibilities easier because providers can apply updates and controls at scale.

These are potential benefits of the model, not guaranteed outcomes. Poor application design, excessive permissions, weak configuration or incomplete monitoring can still create significant security and operational risk.

Serverless is not automatically cheaper, faster, more secure or more resilient. Cost illustrates the point. Consumption-based pricing can work well for intermittent or variable demand, but high execution volumes, inefficient event design, data transfer, logging and additional managed services can materially change the economics.

• Our cloud cost optimisation guide examines this issue in more detail. Sustainable cloud economics depend on architecture, delivery and governance, not infrastructure pricing alone.

Serverless v containers v conventional compute

Serverless, containers and virtual machines are not competing architectural philosophies. They are different execution models and a well-designed enterprise architecture may use all three.

Microsoft’s guidance on choosing a compute service presents the decision as a trade-off between control and management effort. Infrastructure as a Service gives organisations greater control over the environment but requires them to manage more of it. Functions as a Service sits towards the other end of the spectrum, with most of the execution infrastructure operated by the provider.

A simplified comparison looks like this:

These are broad characteristics rather than absolute categories. Managed container platforms can themselves operate on a serverless basis, while the NCSC notes that responsibility for containers varies significantly according to how they are hosted and orchestrated.

Lower infrastructure management also does not guarantee lower operational complexity. With serverless, complexity can move into identity, configuration, event flows, service integration and end-to-end monitoring.

The relevant question is which execution model best fits each component’s requirements for control, scaling, portability, security and operational effort. A single application may reasonably use containers for long-running core services and functions for asynchronous events, integrations or scheduled processing.

Architectural consistency has value, but it should not take priority over workload suitability.

The risks serverless does not remove

Serverless removes some infrastructure responsibilities from your operating model. Other risks remain or become more important because the application is distributed across functions and managed services.

Identity and access

Every interaction between a function, API, queue, database and managed service requires an identity and appropriate permissions.

The provider may operate the infrastructure, but your organisation must still design application identities, access policies, privileged roles and permissions to data. Broad permissions can allow a compromise in one component to spread across the wider service.

Least-privilege access, separation of duties and regular entitlement reviews therefore remain essential.

Observability and audit evidence

Serverless applications can contain many short-lived components connected through APIs, queues and events. Monitoring individual functions is not enough.

A function may complete successfully while the wider business transaction fails several services later. Logs, metrics and traces need to follow the transaction from end to end and show its effect on the business service.

Regulated organisations must also consider whether logs are complete, protected from alteration, retained for the required period and accessible for audit or incident investigation.

Cold starts and latency

Some serverless compute platforms need to initialise a new execution environment before processing a request. This can introduce additional latency, commonly described as a cold start.

Cold starts do not automatically make serverless unsuitable for customer-facing applications. They mean that latency requirements must be measured under realistic conditions and designed for rather than assumed.

Scaling limits and downstream capacity

A function may scale automatically within the provider’s service quotas and scaling limits. The database, legacy API, supplier platform or internal system it invokes may not.

Rapid scaling at one layer can move the bottleneck downstream and, in some cases, overwhelm a dependency. Concurrency controls, throttling, queue design and back-pressure mechanisms are needed to protect the wider service.

Failure, retries and recovery

Event-driven services must be designed for partial failure. Depending on the event source and its delivery guarantees, messages may be delivered more than once, arrive out of order or remain unprocessed when a dependency is unavailable.

Retry behaviour can also make an incident worse if repeated requests continue to hit a failing service. The architecture should define how duplicate events are handled, where failed events are retained, when processing stops and how the complete business transaction is recovered.

Recovery testing should cover the end-to-end service rather than proving only that an individual function can restart.

Deployment and change control

Serverless applications may contain many independently deployed functions, policies, event rules and managed-service configurations.

This can support faster delivery, but it also increases the number of changes that must be controlled and understood. Infrastructure as Code, automated testing, dependency scanning, approval controls and reliable rollback processes remain important, particularly where changes affect regulated data or important business services.

Provider dependency

Serverless applications often integrate closely with provider-specific identity, database, messaging, event-routing and monitoring services. This can reduce portability and make a later move more complex.

Avoiding all provider dependency is neither realistic nor necessarily desirable. Current UK government guidance on managing technical lock-in in the cloud recommends balancing the value of cloud-native capabilities against the cost and difficulty of switching later. It identifies serverless as an example where reduced portability may be acceptable in return for capabilities such as managed patching and deployment.

The objective is not to eliminate dependency. It is to understand the dependency, make a deliberate decision to accept it and retain an appropriate recovery or exit position.

Serverless and cloud concentration risk

Provider dependency becomes particularly important when serverless supports a regulated or business-critical service.

A serverless application may rely on several services from the same cloud provider, including compute, identity, databases, messaging, event routing, monitoring and deployment tooling. Changing provider may therefore require parts of the application to be redesigned rather than simply moved.

This does not make the architecture unsuitable, but the extent of the dependency must be visible.

The issue is particularly clear in UK financial services. On 13 July 2026, Amazon Web Services EMEA SARL, Google Cloud EMEA Limited, Microsoft Ireland Operations Limited and Oracle Corporation UK Limited became the first providers designated under the UK Critical Third Parties regime. The Bank of England explained that the regime addresses the potential systemic impact of disruption to technology services used across multiple firms.

Direct regulatory oversight of a provider does not transfer responsibility away from the firms using its services. The FCA’s outsourcing and operational resilience guidance continues to make firms accountable for their operational resilience and third-party arrangements.

The architecture question is therefore not simply which provider the organisation uses. It is how much of the business service could fail because of a shared dependency.

A serverless workload may depend on:

• one cloud provider
• one region
• a proprietary managed database
• one identity service
• one messaging or event-routing platform
• shared DNS or networking
• one CI/CD platform
• teams whose skills are concentrated around one provider ecosystem

Some of these dependencies may be entirely acceptable. What matters is knowing they exist, understanding the effect of their failure and having a credible recovery, substitution or exit position where the importance of the service requires one.

• Our guide to the UK Critical Third Party regime and cloud concentration risk examines dependency mapping, recoverability and substitutability in more detail.

Which workloads are good candidates for serverless?

Architecture decisions should start with the workload and the business service it supports, not with a preference for a particular technology.

Stronger candidates

Serverless is often a strong option when the workload is:

• event-driven
• intermittent or variable in demand
• bounded in scope and execution time
• capable of running independently
• tolerant of the platform’s latency characteristics
• not dependent on extensive runtime or infrastructure control

Examples include file processing, scheduled tasks, notifications, asynchronous integrations, bounded API operations and event-driven data processing.

Candidates requiring closer assessment

Closer scrutiny is appropriate for:

• customer-facing APIs with strict latency requirements
• workloads processing sensitive or regulated data
• services supporting important or critical business processes
• workloads with significant downstream dependencies
• applications requiring strict data-location, retention or encryption controls
• functions whose failure could create material customer, financial or operational harm

These workloads are not automatically unsuitable for serverless. They require an architecture that explicitly addresses permissions, data controls, monitoring, service limits, resilience, recovery and provider dependency.

Weaker starting points

Serverless may be a weaker initial choice for:

• tightly coupled monoliths
• long-running or continuously utilised compute
• applications requiring extensive runtime or infrastructure control
• workloads with stable demand where consumption pricing offers little advantage
• applications that cannot tolerate the available execution or latency constraints
• legacy estates whose system boundaries and dependencies are not understood

In these situations, the problem often exists before the choice of execution model.

If the organisation cannot confidently explain the system boundaries, data flows, dependencies and business impact of failure, moving the workload to serverless is premature.

How to introduce serverless without creating another migration problem

A common modernisation mistake is choosing the target technology before understanding the existing service. Adopting serverless should begin with the business outcome and workload requirements, not with a preferred cloud product.

Catapult CX’s migration approach is Assess. Map. Move. It is based on a simple principle – moving infrastructure, applications or data safely requires a clear understanding of the current service, its dependencies and what the target architecture needs to achieve.

Assess

Start with the business service and the workload that supports it.

Establish:

• what the service does and who depends on it
• its business criticality and impact of failure
• the data it processes and the controls that apply
• security and regulatory requirements
• performance and latency expectations
• demand patterns and likely execution volumes
• resilience and recovery requirements
• current operational problems
• the outcome the change is intended to improve

Do not begin with a specific product. First determine whether the workload characteristics and required controls suit the serverless model.

Map

Map the workload’s current dependencies and compare them with those created by the proposed architecture.

This should include:

• data sources, locations and flows
• identities and permissions
• upstream and downstream systems
• APIs, integrations and event flows
• external suppliers
• network, DNS and identity services
• monitoring and audit-log requirements
• resilience and recovery dependencies
• deployment and change processes
• managed cloud services
• service quotas and scaling constraints
• internal skills and support ownership

This is where the full serverless trade-off becomes visible. The organisation may remove servers from its direct operating responsibility while introducing deeper dependencies on managed services, provider-specific capabilities or specialist skills.

Move

Introduce serverless selectively rather than treating it as an enterprise-wide architectural conversion.

A suitable starting point may be an event-driven workflow, integration service or bounded component where the potential value is clear, the dependencies are understood and any failure can be contained.

The initial implementation should be representative enough to test the architecture under realistic conditions. Measure:

• reliability and recovery
• performance and latency
• cost under expected and peak demand
• security and auditability
• downstream impact
• deployment and rollback
• support effort
• delivery speed

Use that evidence to decide whether the architecture should be extended, adjusted or limited to particular types of workload.

Catapult CX’s Migrations service applies this approach across cloud, on-premises and hybrid environments, including current-state assessment, dependency mapping, target-state design and controlled migration execution.

Seven Questions to Ask Before Choosing Serverless

Before introducing serverless into a regulated production architecture, answer seven questions.

1. What business service does the workload support?

Start with the business impact rather than the technology. A scheduled reporting task and a customer-payment workflow should not be assessed in the same way.

Establish who depends on the service, the consequences of disruption and the recovery expectations that follow from its criticality.

2. Is the workload suited to serverless execution?

Assess its event patterns, execution time, state, latency requirements, demand profile and dependencies.

Consider not only whether the workload can run on a serverless platform, but whether the model provides a clear operational, financial or delivery advantage.

3. Which responsibilities would move to the provider?

Identify which infrastructure, platform, runtime, patching, scaling and availability responsibilities the selected services would handle.

Do this for each managed service rather than assuming that one shared-responsibility model applies to the entire application.

4. Which responsibilities would remain with the organisation?

Application design, code, configuration, data governance, identity, permissions, monitoring and regulatory accountability do not disappear because the provider manages the underlying infrastructure.

Confirm who will own data location, encryption, key management, audit evidence, change control and incident response.

5. What happens when a component or dependency fails?

Understand the failure domains across the complete service, including provider services, regions, identity, networking and downstream systems.

Test whether the business service can remain within its recovery requirements, not merely whether an individual function can restart.

6. How difficult would the architecture be to change?

Identify the provider-specific services, integrations and skills on which the architecture would depend. Decide whether their value justifies the cost and complexity of switching later.

Where recovery, substitution or exit is required, establish whether the proposed approach is technically and operationally credible.

7. Can the organisation operate and explain the service end to end?

Teams must be able to monitor the complete transaction, identify its dependencies, investigate failures, recover the service and explain who owns each control and risk.

If they cannot do that, the architecture is not ready for regulated production simply because the code runs.

The decision is not about eliminating serverless risk. It is about whether the infrastructure responsibilities removed from the organisation justify the dependencies and controls the architecture introduces.

For many workloads, they will. For others, containers, managed platforms or conventional infrastructure will offer a better balance of control, portability, resilience and operational effort.

Serverless should therefore be a workload decision, not an enterprise-wide technology policy.

Assess whether serverless is right for your workload

Serverless can reduce infrastructure management, but it also changes how applications are secured, monitored, recovered and governed. The right decision depends on the business service, the workload and the dependencies the architecture introduces.

Catapult CX can help you assess workload suitability, map existing and future dependencies, define the required controls and plan a controlled move across cloud, on-premises and hybrid environments.

Find out more about our Migrations service.

Serverless Architecture. Frequently Asked Questions

What is serverless architecture?

Serverless architecture is a cloud model in which the provider operates much of the infrastructure and platform needed to run application code and managed services. Development teams configure the application without directly provisioning, patching or maintaining the underlying servers.

Does serverless mean there are no servers?

No. Servers still provide the compute capacity. ‘Serverless’ means their provisioning and operation are abstracted away from the customer and handled by the cloud provider.

Is serverless the same as Functions as a Service?

No. Functions as a Service, or FaaS, is one form of serverless computing in which code runs in response to events or requests. Serverless architectures may also use managed databases, queues, storage, identity services and event-routing platforms.

Is serverless architecture secure?

It can reduce some infrastructure security responsibilities because the provider manages more of the underlying platform. The organisation must still secure its application code, dependencies, configuration, data, identities and permissions. The precise division depends on the services used, as the NCSC’s cloud shared responsibility guidance explains.

What is the difference between serverless and containers?

Serverless abstracts more of the execution environment and usually requires less infrastructure management. Containers provide greater control over the runtime and deployment environment. The right choice depends on the workload’s requirements for control, portability, scaling, latency and operational effort.

Is serverless cheaper than traditional cloud infrastructure?

It can be. Consumption-based pricing may reduce the amount paid for idle compute capacity when demand is intermittent or variable. However, execution volumes, runtime duration, data transfer, logging, managed services and provisioned capacity all affect the total cost.

Does serverless automatically scale?

Serverless platforms can scale execution capacity automatically, but provider quotas, concurrency restrictions and scaling rates still apply. Databases, APIs and legacy systems may also scale more slowly, moving the bottleneck downstream.

Does serverless improve resilience?

It can remove some infrastructure failure and maintenance concerns, but it does not make the complete business service resilient by default. Regional failure, service quotas, dependencies, retries and recovery must still be designed and tested end to end.

Is serverless suitable for regulated organisations?

Yes, when the workload, provider and controls are appropriate. The organisation must still address data protection, identity, auditability, operational resilience, third-party risk and recovery. The FCA’s outsourcing and operational resilience guidance makes clear that using managed services does not remove a firm’s regulatory accountability.

Can serverless support important or critical business services?

Potentially. The assessment should start with the impact of failure and the service’s recovery requirements. The organisation must demonstrate that its controls, provider dependencies and recovery arrangements are appropriate for the importance of the service.

Does serverless create vendor lock-in?

It can increase provider dependency because applications often use proprietary identity, database, messaging and event-routing services. The UK government’s cloud lock-in guidance recommends weighing the value of those capabilities against the cost and difficulty of switching later.

Which workloads are best suited to serverless?

Serverless often suits event-driven, intermittent or variable workloads that can be divided into bounded units of processing. It may be a weaker fit for long-running compute, tightly coupled applications, continuously utilised workloads or systems requiring extensive runtime and infrastructure control.