You Can Outsource the Work. You Cannot Outsource Accountability for the Risk.

Outsourcing can improve speed, flexibility and cost efficiency, but it increases the need for governance. The supplier can perform the task; the organisation still owns the consequences.

Original article date: 18 January 2024

Article type: Security and operating-model commentary

Executive summary

Outsourcing software development, infrastructure and specialist operational functions is a normal part of modern business.

It can be highly effective.

The security mistake is not outsourcing itself. The mistake is assuming that transferring execution also transfers accountability.

A supplier is responsible for delivering the service described in its contract. The organisation remains responsible for understanding whether that service creates acceptable risk for customers, regulators, shareholders and the business.

As outsourcing increases, internal governance must usually become stronger, not weaker.

Why outsourcing changes the control model

In an internal team, management can often see the people, systems, practices and problems directly.

With an outsourced model, important activities occur across organisational boundaries. That creates additional questions:

• Who sets the requirements?

• Who approves architecture?

• Who owns security decisions?

• Who reviews code and changes?

• Who can see operational metrics?

• Who decides whether a risk is accepted?

• Who owns incident response?

• Who retains the knowledge needed to replace the supplier?

Without clear answers, the organisation can become dependent on a supplier while simultaneously losing the ability to govern the supplier effectively.

Growth and efficiency versus control

A business optimised for rapid growth and a future exit may deliberately keep internal operations lean.

That can be commercially rational.

But a lean operating model does not eliminate operational risk. It changes where the controls must sit.

If development is outsourced, the company still needs enough internal technical capability to assess whether:

• the system is well designed;

• security requirements are being met;

• vulnerabilities are prioritised correctly;

• changes are controlled;

• testing is adequate;

• data is handled appropriately; and

• the product remains maintainable and transferable.

Otherwise the organisation is asking the same team that delivers the work to define whether its own risks are acceptable.

Risk management provides decision visibility

Risk management is not primarily about producing a long register of problems. It is a way of making trade-offs visible.

For example, management may knowingly choose to defer a security improvement because a product release is commercially critical.

That can be a legitimate decision if:

1. the risk is understood;

2. the likely business impact is visible;

3. the decision is made at the right level;

4. compensating controls are considered; and

5. the acceptance is time-bound and reviewed.

What is dangerous is accidental risk acceptance: nobody explicitly decides, so the issue remains unresolved by default.

Standards are useful as governance scaffolding

Frameworks and standards such as ISO/IEC 27001 and relevant payment or industry requirements can provide a useful baseline for control and evidence.

Their value is not the badge alone. Their value is the discipline they can impose around areas such as:

• access management;

• supplier relationships;

• change control;

• incident management;

• vulnerability management;

• business continuity;

• asset ownership; and

• management review.

For outsourced organisations, this evidence helps management see whether expected controls are actually operating.

Supplier risk is also knowledge risk

One of the least visible outsourcing risks is the gradual loss of internal knowledge.

A company may know what a supplier delivers but no longer understand in sufficient detail:

• how the system is built;

• why architectural decisions were made;

• how deployments work;

• where operational dependencies sit;

• how data moves;

• what would be required to move to another supplier; or

• which technical compromises have accumulated over time.

This becomes particularly important during incidents, acquisitions, major upgrades or supplier failure.

Portability should be designed in

A mature outsourcing strategy should preserve the organisation's ability to change direction.

That means paying attention to:

• source-code ownership and access;

• reproducible builds;

• infrastructure-as-code where appropriate;

• documented interfaces;

• portable data formats;

• backup ownership;

• administrator access;

• cloud and vendor lock-in;

• deployment documentation; and

• realistic exit procedures.

A supplier relationship is much healthier when both parties know that the customer can leave in an orderly way.

Security incidents reveal governance weaknesses

When a business suffers repeated incidents, the most useful question is not simply "Which developer made a mistake?"

The better questions are:

• Was the risk known?

• Who owned it?

• Was remediation funded?

• Were controls tested?

• Was the supplier monitored?

• Did management receive useful risk information?

• Could the organisation respond quickly?

• Were lessons from previous incidents implemented?

Repeated incidents often indicate a systemic governance problem rather than a sequence of isolated technical errors.

People and continuity

High turnover in critical technical or security roles creates operational risk because specialised knowledge takes time to build.

A company should therefore understand:

• which roles are genuinely critical;

• how long replacement capability takes to develop;

• whether knowledge is documented;

• whether suppliers hold knowledge that the company itself no longer has;

• why key people leave; and

• whether the operating model remains sustainable during periods of change.

This is more useful than treating culture or employee sentiment as an abstract ESG score. The security question is whether the organisation can retain the capability required to make good decisions and operate its systems safely.

A practical governance model for outsourced development

1. Internal product ownership

The organisation defines business outcomes, priorities and acceptance criteria.

2. Independent architecture and security oversight

Important design and security decisions are reviewed by people who are not measured only on delivery speed.

3. Explicit risk acceptance

Material risks are documented, prioritised and accepted at the appropriate management level.

4. Engineering evidence

Testing, code review, vulnerability management, release records and operational metrics provide evidence that controls are working.

5. Supplier performance review

Measure more than deadlines and cost. Include quality, defect rates, security findings, resilience, documentation and maintainability.

6. Exit readiness

Maintain the practical ability to transfer the service, source code, data and operational knowledge elsewhere.

Oversight does not mean bureaucracy

Governance is sometimes treated as the opposite of speed.

Bad governance certainly can be.

Good governance should make decisions faster because responsibilities, evidence and escalation paths are already clear.

A lightweight but explicit model is often better than a large control framework that nobody uses.

Conclusion

Outsourcing can be an excellent way to build and operate technology. It becomes dangerous when the customer outsources not only the execution but also the ability to understand and challenge the work.

The central principle is simple:

The supplier can own the task. The organisation still owns the outcome.

That means retaining enough internal capability to specify, oversee, test, challenge, measure and, when necessary, replace the outsourced service.

In a highly outsourced business, that governance capability is not overhead. It is part of the product.