UK Cyber Security and Resilience Bill: Does It Apply to Software Agencies and MSPs?

A UK software company is not automatically in scope of the Cyber Security and Resilience Bill simply because it writes software, hosts a website, or fixes bugs for clients.

The current government definition focuses on something more specific: ongoing contracted management of a customer's IT systems, combined with connection or access to those systems. That distinction means a one-off software build and handover can sit on one side of the line, while an ongoing DevOps, cloud-management, application-management or remote-support contract can sit on the other.

The Bill is still going through Parliament and is not yet law. As of 18 August 2026, it has completed second reading in the House of Lords and committee stage is scheduled to begin on 1 September 2026. Detailed security requirements, incident thresholds and implementation rules are expected to follow through secondary legislation if the Bill receives Royal Assent.

For software agencies and managed IT providers, the useful question is therefore:

Does our commercial relationship stop at delivering software, or do we continue managing systems that the customer relies on?

This guide explains that boundary and what to prepare without pretending the final rules already exist.

What is the Cyber Security and Resilience Bill?

The Cyber Security and Resilience (Network and Information Systems) Bill is proposed UK legislation intended to expand and strengthen the existing Network and Information Systems Regulations 2018.

Among other changes, the Bill would bring qualifying relevant managed service providers, or RMSPs, directly into the regulatory regime.

The government's current RMSP factsheet says the measure is aimed at medium and large managed service providers because they can have extensive access to customer systems and can create "one-to-many" cyber risk when compromised.

If a provider meets the proposed RMSP definition, it would be expected to:

• register with the Information Commission
• implement appropriate and proportionate cyber security measures
• manage risks to the systems used to provide the managed service
• report qualifying cyber incidents
• cooperate with regulatory oversight and enforcement

The important word for software businesses is managed.

The Bill is not simply creating a licence for everyone who builds technology.

Is the Bill already in force?

No.

As of 18 August 2026, the Bill is still moving through Parliament.

The UK Parliament stages page shows that:

• Commons stages have been completed
• Lords first reading took place on 17 June 2026
• Lords second reading took place on 14 July 2026
• Lords committee stage is scheduled to begin on 1 September 2026

Future parliamentary dates can change.

Government factsheets also make clear that several operational details would be introduced through secondary legislation after Royal Assent.

So businesses should prepare for the direction of travel, but should not market themselves as "fully compliant with the new Act" or hard-code unfinalised reporting thresholds into software today.

This article is a practical software and operational interpretation of the current Bill and government factsheets, not legal advice.

What is a "relevant managed service provider"?

The government's current definition has several moving parts.

A managed service is broadly described as a service:

1. provided under a contract to another person or organisation
2. involving ongoing management of the customer's information technology systems
3. where that ongoing management may include support, maintenance, monitoring, active administration or similar activity
4. where the provider connects to or otherwise obtains access to network and information systems relied on by the customer

The connection can be remote, on the customer's premises, or through another person acting on the provider's behalf.

The proposed RMSP measure then applies to providers meeting the statutory definition and size conditions. Government guidance currently describes the main measure as applying to medium and large managed service providers, with small and micro providers generally exempt from the RMSP measure itself.

That produces a useful four-part test:

Contract with customer
        ↓
Ongoing IT management?
        ↓
Access/connection to customer systems?
        ↓
Provider meets RMSP size/status conditions?
        ↓
Potential RMSP scope

If one of the central managed-service elements is missing, the service may fall outside the RMSP definition.

Does a normal software development agency fall within scope?

A one-off software development engagement is not automatically a managed service.

The government's current factsheet specifically gives an out-of-scope example of a company that installs or integrates information systems but does not manage those systems or networks after installation.

It also says a company selling software as a product to UK business customers would not meet the "ongoing management" definition for that service, even where it provides ad-hoc remote patches.

So a typical project can look like:

Discovery
   ↓
Design
   ↓
Build
   ↓
Testing
   ↓
Deployment
   ↓
Handover
   ↓
Customer manages system

That looks materially different from:

Build
   ↓
Deploy
   ↓
Agency keeps privileged access
   ↓
Monitors production
   ↓
Patches systems
   ↓
Manages cloud resources
   ↓
Responds to incidents
   ↓
Optimises performance every month

The second model begins to resemble ongoing managed IT.

The regulatory boundary is about what you continue to operate, not merely what you originally built.

Where can a software agency cross into managed-service territory?

Many modern agencies no longer stop at handover.

They sell recurring services such as:

• application management
• DevOps retainers
• cloud infrastructure management
• production monitoring
• database administration
• security monitoring
• patching
• backup management
• incident response
• performance optimisation
• release management
• managed helpdesk/support

The government's current RMSP factsheet explicitly lists an IT company that provides ongoing management of a cloud service, including configuration, maintenance, event monitoring and performance optimisation, as an example that would be in scope if the other RMSP conditions are met.

It also includes companies that remotely manage customer IT systems to support business processes.

That matters for agencies because the commercial transition can happen gradually.

A contract originally sold as:

"We will maintain the app after launch"

may in practice include:

AWS / Azure / GCP administration
+
database access
+
production logs
+
scheduled deployments
+
security patches
+
uptime monitoring
+
incident response

At that point, the service is much closer to managed infrastructure or application management than occasional software support.

A practical software-agency scope matrix

The following matrix is based on the current government examples and is meant as a screening tool, not a legal determination.

The contract name is not decisive.

Calling something "technical support" does not necessarily make it out of scope if the actual service is continuous remote administration.

Likewise, calling a contract "managed services" does not automatically settle the legal classification if the provider never manages or accesses customer IT.

Operational reality matters.

Is DevOps specifically relevant?

Yes, because DevOps can sit directly on the boundary between software delivery and ongoing operations.

Earlier government consultation material on managed-service scope explicitly discussed software engineering, DevOps, application modernisation and application management. The current Bill factsheet now frames the test more generally around ongoing management and access, which is the safer current standard to use.

Consider two DevOps arrangements.

Project-based DevOps

The agency:

• creates infrastructure configuration
• sets up CI/CD
• deploys the first release
• documents the environment
• hands credentials and operational responsibility to the customer

That looks closer to one-off implementation.

Managed DevOps

The agency:

• remains administrator of the production cloud account
• runs releases for the customer
• monitors incidents
• patches infrastructure
• manages secrets
• changes firewall/network configuration
• tunes performance
• manages backups

That looks much closer to ongoing management of customer IT systems.

So the relevant question is not:

"Do we use DevOps?"

It is:

"Who remains operationally responsible for the customer's production systems after delivery?"

What about SaaS companies?

The government's current factsheet gives a useful boundary:

A software company selling software as a product to UK business customers would not meet the definition of ongoing management for that service, including where it may provide ad-hoc patch updates remotely.

That does not mean every SaaS or digital-service business is automatically outside the wider NIS framework. The Bill separately deals with digital service providers and other categories.

For the specific RMSP question, though, selling a product is not the same thing as managing the customer's IT environment.

A SaaS business could also run a separate managed service.

For example:

SaaS subscription
→ product service

Optional managed integration package
→ provider remotely manages customer's ERP connector and cloud jobs

One company can have different service lines with different regulatory characteristics.

That is why businesses should classify services, not only company labels.

What about small software agencies?

The current RMSP factsheet says the proposed RMSP measure applies to providers that are not small or micro enterprises.

So many small development agencies may fall outside the main RMSP measure on size grounds even if they offer services resembling managed IT.

However, that should not become:

"We are small, therefore none of this matters."

There are at least three reasons.

1. The Bill is not final

Definitions and secondary legislation still matter.

2. Small suppliers can still matter to regulated customers

A customer that is itself regulated may impose stronger contractual requirements on suppliers that have privileged access.

3. The Bill includes a critical-supplier mechanism

Government materials say small and micro suppliers can potentially be designated as critical suppliers where statutory criteria are met.

Most small software agencies will not suddenly become regulated critical suppliers.

But size alone is not a reason to ignore privileged-access risk.

Good managed-service security is useful before it becomes a legal obligation.

What duties could apply to an RMSP?

If the Bill is enacted and the relevant provisions commence, current government factsheets describe several major duties.

1. Registration

RMSPs would be regulated by the Information Commission.

The government says relevant providers would need to register and provide specified information.

The implementation factsheet says RMSPs would have three months after the amended regulations commence to register.

That does not mean businesses should register today.

The regime has not commenced yet.

2. Appropriate and proportionate cyber security measures

RMSPs would need to manage risks to the network and information systems supporting the managed service.

The exact technical detail is expected through secondary legislation.

A mature managed-service risk model includes:

Identity
Access
Infrastructure
Applications
Data
Monitoring
Recovery
Incident response
Supplier dependencies

The provider needs to understand how compromise of its own systems could spread into customer environments.

3. Incident reporting

The current incident-reporting factsheet proposes a two-stage structure.

For reportable incidents:

• an initial notification would be required within 24 hours of becoming aware of the incident
• a fuller report would be required within 72 hours

The National Cyber Security Centre would be informed alongside the regulator.

For RMSPs and relevant digital service providers, current government guidance also says that after the full notification they would need to identify customers likely to be affected and notify them.

The exact thresholds for what counts as a sufficiently significant incident are still expected to be set through secondary legislation.

So an agency should prepare the process, not guess the final threshold.

4. Regulatory oversight and enforcement

The Bill would strengthen regulators' enforcement powers.

The government's current enforcement factsheet proposes maximum penalties of:

• up to £17 million or 4% of worldwide turnover, whichever is higher, for more serious breaches
• up to £10 million or 2% of worldwide turnover, whichever is higher, for less serious breaches

The exact turnover mechanics and further details are still expected in secondary legislation.

These are proposed maximums, not automatic fines for every security incident.

The regulator is expected to act proportionately.

Why the 24-hour rule changes incident-response design

Many software agencies handle incidents informally.

A typical sequence can look like:

Developer sees alert
      ↓
Checks Slack
      ↓
Messages technical lead
      ↓
Waits for cloud engineer
      ↓
Customer asks what happened
      ↓
Team begins writing timeline

That is manageable when reporting is purely contractual.

It becomes risky when a regulatory clock may start at awareness.

A better managed-service design records:

Incident detected
      ↓
Incident ID created
      ↓
Awareness timestamp preserved
      ↓
Severity / regulatory triage
      ↓
Customer impact mapped
      ↓
Evidence collected
      ↓
24-hour notification decision
      ↓
72-hour fuller report workflow

Even before the Bill becomes law, that process improves operational discipline.

What should a software agency prepare now?

Do not start by buying another security product.

Start by understanding what you actually manage.

Step 1: classify every recurring service

Create a service register.

For each offering, record:

• one-off or ongoing
• systems being managed
• whether the agency has customer-system access
• level of privilege
• cloud/admin access
• monitoring responsibility
• patching responsibility
• backup responsibility
• incident-response responsibility
• customer dependency on the service

Example:

This exercise is useful even if lawyers later determine that the business is outside statutory scope.

Step 2: inventory privileged customer access

Many agencies do not have a reliable answer to:

"Which employees can access which customer production systems today?"

Build an access inventory covering:

• cloud accounts
• servers
• databases
• CI/CD
• GitHub/GitLab
• DNS
• domain registrars
• Firebase/Supabase
• payment dashboards
• monitoring platforms
• SSH keys
• VPNs
• customer admin portals

For each access path, record:

Person/service account
→ Customer
→ System
→ Privilege
→ Reason
→ Authentication method
→ Last review

If a managed-service provider is compromised, stale privileged access is exactly the sort of connection that can turn one incident into many customer incidents.

Step 3: reduce permanent privilege

Where feasible, move from:

everyone has permanent admin

toward:

least privilege
+
named identities
+
MFA
+
short-lived elevation
+
customer-specific access boundaries
+
audit logging

Avoid shared root/admin credentials.

Avoid one deployment key that unlocks several unrelated customers.

Avoid engineers retaining access indefinitely after a support contract ends.

Step 4: separate customers operationally

Strong separation can include:

• customer-specific cloud accounts/projects where appropriate
• separate secrets
• scoped service accounts
• independent access boundaries
• tenant-aware logging
• separate backup policies
• per-customer deployment credentials

The goal is to reduce blast radius.

A compromised tool used for Customer A should not automatically expose Customers B through Z.

Step 5: build an incident evidence trail

At minimum preserve:

• detection time
• awareness time
• affected systems
• affected customers
• indicators of compromise
• actions taken
• decision makers
• containment actions
• customer notifications
• regulator notifications if applicable
• recovery evidence

Do not let the only incident record be a disappearing chat thread.

Step 6: map customer dependencies

A customer may rely on your service for:

• payroll
• bookings
• payments
• logistics
• healthcare operations
• ecommerce
• internal communications
• authentication
• inventory
• data processing

That context matters when evaluating impact.

Step 7: review contracts

Contracts should accurately describe:

• what systems the provider manages
• security responsibilities
• customer responsibilities
• incident notification channels
• escalation contacts
• support hours
• backup responsibilities
• recovery commitments
• access termination
• subcontractors
• data-processing obligations

A contract that says "maintenance" while the provider actually operates the entire production estate creates ambiguity before a regulator ever appears.

A better managed-service architecture

For agencies operating customer systems, central convenience should not become central compromise.

A safer conceptual architecture is:

Agency identity provider
        ↓
Strong MFA / device controls
        ↓
Privileged-access workflow
        ↓
Customer-specific scoped access
        ↓
Central security monitoring
        ↓
Incident-management system
        ↓
Customer impact map
        ↓
Notification / recovery workflow

The provider can still operate efficiently.

What it should avoid is a single undifferentiated admin plane where one stolen credential exposes every client.

A practical RMSP screening decision tree

Use this as an internal first pass.

Question 1: Is the service provided under contract to another organisation?

If no, the RMSP service definition is less likely to apply. If yes, continue.

Question 2: Is the work ongoing management of IT systems?

Examples include support and maintenance, monitoring, active administration, application management, cloud management and remote IT support.

If it is purely a one-off build/integration with no continuing management, current government examples point outside the RMSP measure for that service.

Question 3: Do you connect to or obtain access to systems the customer relies on?

If you retain production access, cloud admin, database access, monitoring access or similar operational access, continue.

If you only provide advice with no system management/access, the current examples point away from RMSP status.

Question 4: Does the provider meet the size/status conditions?

The current factsheet says small and micro providers are generally excluded from the RMSP definition, subject to the wider framework including potential critical-supplier designation.

Question 5: Are there specific statutory exemptions or another regulated category?

This is where legal review becomes useful.

The result should be:

Potentially in scope
→ legal/regulatory classification
→ service and access inventory
→ security readiness
→ monitor secondary legislation

What should agencies not do yet?

Do not redesign contracts around guessed final thresholds

Incident significance thresholds are still due through secondary legislation.

Do not build a regulator-reporting API that does not exist

Prepare structured incident data and internal workflows. Wait for final submission mechanisms.

Do not claim the Bill is already law

It is currently before Parliament.

Do not assume "software company" automatically means out of scope

A product sale may be outside the RMSP measure while a separate managed-cloud or application-management service may fit it.

Do not assume "small company" means no customer security obligations

Contracts, customer requirements, data protection, supply-chain security and possible critical-supplier mechanisms can still matter.

Do not treat compliance as a certificate

The security value comes from reducing risk:

fewer standing privileges
+
better customer isolation
+
better monitoring
+
faster incident understanding
+
tested recovery

A document saying "compliant" does not contain an attacker.

How should a growing software agency structure service lines?

Separate project delivery:

Design
Build
Deploy
Handover

from managed operations:

Monitor
Maintain
Patch
Administer
Respond
Recover

That does not mean a company should avoid managed services.

Recurring application and cloud management can be commercially valuable.

It means the business should price and operate them as a different risk category.

Managed operations need:

• defined support scope
• on-call ownership
• access governance
• monitoring
• incident response
• backup/recovery
• security controls
• auditability
• customer communication

If the monthly fee does not cover those responsibilities, the contract may be economically mispriced even before regulatory duties arrive.

Why this matters commercially, not just legally

A provider with deep access to customer production systems is part of the customer's attack surface.

That affects:

• enterprise procurement
• cyber insurance questions
• vendor-security questionnaires
• security clauses
• customer trust
• incident liability
• onboarding time
• ability to sell into regulated sectors

Agencies that build a mature managed-service operating model can therefore gain value before any statutory deadline.

The strongest sales message is not:

"We comply with a Bill that is still changing."

It is:

"We know exactly what we manage, who can access it, how we detect compromise, how we isolate customers, and how we recover."

That is an operational capability a buyer can evaluate.

FAQs

Does the Cyber Security and Resilience Bill apply to software development agencies?

Not automatically. The current RMSP definition focuses on ongoing contracted management of customer IT systems combined with connection or access to those systems. A one-off build/integration with no ongoing management is specifically given as an out-of-scope example for the RMSP measure.

Is a software company with a SaaS product an RMSP?

Not simply because it sells software. The government's current factsheet says software sold as a product, including with ad-hoc remote patching, does not meet the ongoing-management definition for that service. Separate managed-service or digital-service activities may need their own assessment.

Can a DevOps agency become an RMSP?

Potentially. If the DevOps service involves ongoing administration, monitoring, configuration or maintenance of customer IT/cloud systems with access to those systems, it can resemble the managed-service examples described by government.

Are small software agencies exempt?

The current RMSP factsheet says the RMSP definition excludes small and micro enterprises. However, small suppliers can still face customer security obligations and the wider Bill includes mechanisms relating to designated critical suppliers. The final position should be checked against enacted legislation and secondary rules.

What are the proposed incident-reporting times?

The current Bill factsheet proposes an initial notification within 24 hours of awareness of a reportable incident and a fuller notification within 72 hours. The detailed significance thresholds are expected through secondary legislation.

When does the Bill take effect?

It has not yet taken effect. As of 18 August 2026 the Bill is in the House of Lords, with committee stage scheduled to begin on 1 September 2026. Relevant managed-service provisions would require commencement and secondary legislation after Royal Assent.

Conclusion

For software agencies, the Cyber Security and Resilience Bill is not best understood as:

"software companies are being regulated."

The more accurate question is:

"Have we become the ongoing operator of customer IT?"

The current government boundary is relatively clear at a high level:

One-off build / integration / product sale
→ generally weaker RMSP characteristics

Ongoing application / cloud / infrastructure management
+ customer-system access
→ stronger RMSP characteristics

The Bill is still moving through Parliament, and important operational details remain to be set later.

So the right preparation in August 2026 is not speculative compliance theatre.

It is to:

• classify recurring service lines
• inventory privileged access
• separate customer environments
• strengthen identity and logging
• formalise incident response
• map customer impact
• clarify contracts
• monitor the Bill and secondary legislation

Those are useful controls whether the eventual legal answer for a particular agency is "in scope" or "out of scope".

If your software business is moving from project delivery into long-term application, cloud or platform operations, Softotic's custom software development service can help design maintainable application and operational architecture, while web application development can support secure management portals and operational tooling.

Sources and references

• UK Parliament: Cyber Security and Resilience (Network and Information Systems) Bill
• UK Parliament: Bill stages
• GOV.UK: Relevant managed service providers factsheet
• GOV.UK: Incident reporting factsheet
• GOV.UK: Enforcement factsheet
• GOV.UK: Cyber Security and Resilience Bill factsheets