What breaks when a vendor does the work instead of transferring it?

Why This Matters for Security Teams

When a vendor performs the work instead of transferring it, the organisation may receive a service outcome without gaining the operational capability to sustain it. That distinction matters because security programmes depend on repeatable internal processes for change control, incident response, access reviews, and recovery. If those processes remain outside the customer’s control, resilience becomes contingent on vendor availability rather than internal readiness. NIST’s NIST Cybersecurity Framework 2.0 places clear weight on governance and operational continuity, which is exactly where this model tends to fail.

The practical risk is not only slower delivery. It is also weaker institutional knowledge: the people closest to the risk cannot safely change the platform, investigate failures, or verify that controls still work after an update. Over time, the organisation loses the ability to challenge the vendor’s assumptions and becomes dependent on a managed service for basic operational competence. In practice, many security teams discover this only after a major incident or urgent change request has already exposed that they cannot run the process themselves.

How It Works in Practice

A healthy transfer model gives the customer enough knowledge, access, and authority to operate the capability independently, even if a supplier still provides support. That usually means documented procedures, admin access where appropriate, named internal owners, and a transition plan that includes shadowing, handover checkpoints, and exit criteria. By contrast, vendor-led delivery often keeps configuration knowledge, decision logic, and troubleshooting pathways inside the supplier’s environment.

In mature programmes, transfer should cover more than login credentials. It should include the operational details that make the service governable:

• How changes are approved, tested, and rolled back
• Which logs, alerts, and dashboards the customer can access directly
• How dependencies are mapped across identity, cloud, endpoint, and ticketing systems
• Who can make urgent changes during an incident without waiting for a third party
• What happens if the vendor relationship ends or support is delayed

This is where identity and privilege intersect with service design. If a supplier retains exclusive administrative control, the customer may not have true operational ownership, only contractual access. For identity-dependent services, current guidance suggests that least privilege, separation of duties, and clear ownership of privileged access should be maintained internally wherever feasible. The CISA Zero Trust Maturity Model is useful here because it reinforces continuous verification and explicit control boundaries, even in outsourced operating models. The MITRE ATT&CK knowledge base is also relevant when vendor-operated environments reduce visibility into attack paths, privileged use, or lateral movement opportunities.

Good transfer is measurable. If the customer cannot execute routine updates, triage faults, or restore service without vendor intervention, then the work has not really been transferred. These controls tend to break down when integrations are tightly coupled to a supplier-owned console or when the customer never receives enough access to test recovery in a live-like environment.

Common Variations and Edge Cases

Tighter supplier control often reduces short-term operational burden, requiring organisations to balance speed and convenience against autonomy and recoverability. That tradeoff can be acceptable for low-risk utilities, but it becomes fragile when the service supports IAM, PAM, NHI governance, or incident response. In those cases, best practice is evolving toward shared responsibility models that still preserve customer competence for core tasks.

There are also edge cases where full transfer is not realistic. Regulated platforms, proprietary appliances, and highly specialised managed services may require the vendor to retain some operational control. Even then, the customer should retain enough oversight to validate changes, review access, and invoke an exit plan. Where the service touches privileged access or secrets management, the operational question is not whether the vendor can do the task faster, but whether the customer can detect, approve, and recover from the task independently.

This is especially important in environments with multiple suppliers or complex integrations. If one vendor is responsible for patching, another for identity workflows, and a third for monitoring, accountability can become fragmented. The result is a control gap that no single party fully owns. Clear operating agreements, internal runbooks, and regular recovery exercises are the practical answer, not assumption-based trust.

Related resources from NHI Mgmt Group

• What breaks when identity governance is treated as admin work instead of security work?
• What breaks when buyers rely on vendor-supplied proof instead of independent verification?
• What breaks when Oracle SoD reporting relies on assigned roles instead of effective access?
• What breaks when privilege duration is measured in calendar time instead of task time?