External IT Support: Risks and Issues

Over the past few months, I’ve been looking more closely at something that raises concerns for me.

How much real, practical control organisations retain when their IT service is delivered by an external provider.

The relationship may be great and the SLA met, but three patterns keep surfacing:

• Concentrated privileged access (single points of failure)

• Remote access to sensitive data without meaningful friction

• Customers being charged for access to their own governance information

Individually, each may seem manageable. Together, they point to a real fragility.

1. When Support Becomes Structural Dependency

Many organisations operate in environments where their IT provider:

• Holds global administrative rights

• Controls identity and access configuration

• Manages backup platforms

• Oversees security tooling and logging

• Configures conditional access and RBAC

  
  

That creates a real dependency.

If the provider is the only party with meaningful administrative capability, then the organisation has effectively outsourced both control and visibility of this high risk domain.

Single points of failure like this are rarely obvious until something goes wrong.

2. Remote Access Without Friction

Remote management tooling is now standard. It enables fast response, patching, configuration and support.

But the governance question is how it is controlled.

• Is access persistent or time-bound?

• Are actions logged and attributable to named individuals?

• Does the customer have visibility of those logs?

• Can large-scale changes be pushed without explicit oversight?

  
  

If a provider can access systems containing sensitive personal data without secondary checks or customer awareness like pop-ups or a permission, then technically the organisation is relying almost entirely on trust.

3. When Governance Information Is Behind a Paywall

A recurring issue I’ve seen is where a customer asks their IT provider for a basic report such as a breakdown of who has administrative access or starters and leavers.

And the response is: “That will be chargeable.”

Technically, that may be contractually valid.

But from a governance perspective, it raises a real red flag.

If an organisation needs to pay a third party to understand:

• Who has privileged access

• How roles are configured

• What permissions exist

• How access is structured

…then they do not have operational visibility of their own environment.

In many cases, if the customer retained even limited read-only or reporting access, they could extract that information themselves, instantly and at no cost.

This lack of control is concerning to me.

4. Control vs Convenience

Often, these arrangements evolve for convenience:

“It’s easier if they just manage everything.” because “We don’t have in-house expertise.” and “They’re the technical specialists.” This is particularly the case for smaller charities or community providers we support.

But over time, convenience can become:

• Exclusive admin access

• Restricted client permissions

• Opaque role structures

• Reporting that requires invoicing

At that point, the provider is arguably gatekeeping the IT environment, not just supporting it.

That creates both operational and governance risk.

5. Why This Matters for Data Protection

From a data protection standpoint, this has real implications.

If an organisation cannot independently verify:

• Who has access to sensitive data

• Whether least privilege is enforced

• How special category data is protected

• What changes have been made

  
  

…then oversight is weakened.

The legal status of “data controller” assumes meaningful control.

But meaningful control requires visibility.

And visibility should not depend on whether a purchase order has been raised.

6. The Single Point of Failure You Don’t See

Single points of failure aren’t always technical.

They can be informational.

If:

• Only the provider can generate access reports

• Only the provider can export logs

• Only the provider can modify role assignments

• Only the provider understands the architecture

…then the organisation’s resilience depends on uninterrupted cooperation.

Resilience requires shared knowledge and recoverability, not just technical uptime.

7. What Good Looks Like

Good governance doesn’t mean distrusting your IT provider but you should be designing the relationship so that:

• Privileged access is attributable and limited

• MFA is enforced universally

• Remote access is logged and visible

• Backup control is not exclusively external

• Customers retain reporting-level visibility of their own RBAC and permissions

• Access transparency is not chargeable

The ability to understand your own environment should not be treated as a premium add-on.

The Real Question

The key question is not:

“Is our IT provider competent?”

It’s:

“If we needed to independently evidence control tomorrow, could we?”

Single points of failure, unrestricted remote access, and paywalled governance information don’t usually cause immediate disruption but they can slowly erode resilience.

Emma Kitcher, Privacy Nerd