A captive IT unit is a separate legal entity created to provide technology services to a parent company. Banks use this structure to centralise delivery, manage costs, or access talent in a different geography while keeping the operational work closely tied to the core business.
What a captive IT unit is in practice
A captive IT unit is not just an outsourced vendor with a contract. It is a legally distinct delivery entity, usually created to concentrate technology work, standardise operating models, and separate employment, tax, or regulatory arrangements from the parent while preserving tight business alignment.
That structure matters because governance sits at the boundary between enterprise oversight and service delivery. The parent still depends on the unit for core technology outcomes, but legal separation changes how accountability, intercompany charging, labour arrangements, and operating authority are organised.
Why organisations use captive structures
Captives are often chosen when a parent wants more control than a third-party outsourcer can provide, but still needs geographic flexibility or a different cost base. They are especially common in banking and other regulated sectors where delivery consistency, talent access, and process control are strategic concerns.
The model can support centralised engineering, shared platforms, and standardised operations across business lines. It may also help organisations build internal capability in a lower-cost location while keeping the work governed as part of the enterprise rather than fully externalised.
Governance, control, and operating model implications
A captive IT unit changes the operating model, not the security obligations. The parent organisation still needs clear ownership for architecture, change approval, access control, data handling, resilience, and oversight of the services the captive provides.
Because the unit is separate legal entity, controls often need explicit contracts, intercompany service definitions, and escalation paths to keep responsibilities unambiguous. That is especially important where the captive supports regulated workloads, production support, privileged operations, or customer-impacting systems.
The structure can also affect auditability and reporting. Security and operational controls need to be visible across the organisational boundary so that the parent can evidence oversight without treating the captive as a black box.
Where the model breaks down
The captive model works best when it is treated as an operating choice with strong governance, not as a loophole for shifting risk away from the parent. If accountability is unclear, the result is often fragmented responsibility, inconsistent control execution, and weaker response during incidents or service degradation.
It can also create concentration risk if too much critical delivery, knowledge, or privileged operational capability is concentrated in one entity or location. That makes dependency management, succession planning, and resilience design more important than they might be in a looser vendor model.
Risk and Threat Considerations
A captive IT unit can reduce some outsourcing risks, but it can also concentrate operational dependency inside a legally separate entity. If the captive is under-governed, the parent may inherit visibility gaps, weak accountability, or exposure to the same control failures that would matter in any internal technology function.
Failure mechanism: The main failure mode is misalignment between legal separation and operational control, where access, change authority, or incident responsibility is assumed rather than explicitly governed. That can slow response, blur ownership, and leave critical systems exposed to inconsistent enforcement.
Impact: The likely impact is service disruption, audit findings, or wider security exposure if the captive becomes a single point of operational dependency for core business technology.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Captive IT units require defining enterprise and legal operating context. |
| GV.RM-01 — Risk Management Strategy | Captive structures create concentration, accountability, and service-dependency risk. | |
| PR.AA-05 — Least Privilege and Authorization | Captive IT units often operate privileged systems and need tight authorization. | |
| Recommendation — Document the captive’s role, boundaries, and dependencies in enterprise governance. Assess captive delivery as a formal enterprise risk with clear ownership. Enforce least-privilege access for captive staff and administrators. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | A captive’s privileged operations should be constrained to needed access only. |
| Recommendation — Limit captive personnel to the minimum access required for their duties. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Separate entities still need controlled access across parent and captive boundaries. |
| Recommendation — Define and enforce access control rules across the captive relationship. | ||
Practitioner Guidance
Governance implication: Treat the captive as a controlled extension of the enterprise operating model, with explicit accountability for security, resilience, and privileged operations. The parent should be able to demonstrate oversight even when delivery sits in a separate legal entity.
What to watch for: Watch for unclear service boundaries, duplicated ownership, or unmanaged access paths between the parent and the captive. Those are the signals that the structure is becoming a governance wrapper rather than a disciplined delivery model.
Related resources from NHI Mgmt Group
- How should organisations govern agent identities that belong to a business unit?
- Why do APIs need fuzz testing if they already have unit and integration tests?
- What breaks when organisations rely only on unit tests for LLM workflows?
- Who should be accountable when one business unit's agent consumes another team's resources?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
