One Network, Three Risk Appetites

A diversified group has a strong reason to share technology. One network team, one security operations centre, one service desk and one set of vendor contracts cost less than three of each. For years that logic was hard to argue with.

My view is that it now needs a second test. When one business in the group is a regulated lender and another runs stores or malls full of shopper data, a shared service carries the strictest obligation of any business it serves. Sharing is still often right. It is no longer automatically cheap.

I work across NBFC, retail and B2B wholesale businesses within one group, so this is a question I think about as a design problem rather than an org chart. This piece is for group CTOs, CIOs and CFOs deciding which services to share, which to ring-fence and which to separate.

The short version

Shared IT services save money until one business's regulation sets the standard for all of them. Decide sharing service by service, using the evidence each business must produce and the damage a failure would cause. Then state each decision as a cost and a risk with a named owner.

• Decide sharing per service, not per organisation.
• Let the strictest regulated user set the service's evidence standard.
• Segment networks by risk, not by building or company.
• Write each regulated entity's clocks into internal service agreements.
• Watch vendor concentration across the whole group.
• Put a number and an owner on every sharing decision.

This article sits inside the digital transformation advisory cluster, where the wider argument is set out in full.

Why sharing stops being free

The saving from shared services is visible and immediate. The cost arrives later and in less obvious forms.

Consider a group where a regulated lender shares a security operations centre with retail businesses. RBI's July 2026 cyber directions for NBFCs expect larger NBFCs to report incidents within six hours of detection, give their auditors and RBI access to records held by service providers, test business continuity across interconnected systems including those of vendors, and manage concentration risk and single points of failure in their technology supply chain. The retail businesses have different obligations, including the DPDP duties that apply in full from May 2027.

A shared SOC serving both must meet the lender's reporting clock, evidence standard and audit access for every event it handles, or it must separate the lender's events cleanly. Either way, the cost of the service rises to match its most demanding user. The saving is still real, but it is smaller than the original business case said.

Check with compliance how your regulator treats services provided by group companies. My recommendation is to govern an internal shared service with the same rigour as an outside provider, whatever the formal position.

A sharing test for each service

I would decide each shared service on four questions. This is a proposed test, not an established standard:

• Evidence. What must each business be able to prove about this service, to whom, and how fast?
• Blast radius. If this service fails or is breached, which businesses are affected, and what does each lose?
• Scale benefit. How much does sharing actually save compared with separate provision?
• Change pace. Do the businesses need the service to change at the same speed?

The answers usually point to one of three outcomes.

Share fully

• When it fits: similar evidence needs, contained blast radius, clear scale benefit.
• Pros: lowest cost, one set of skills.
• Cons: the strictest requirement applies to everyone.
• Cost and risk: low cost, moderate concentration risk.
• My view: right for commodity services such as end-user devices and email.

Share with a ring-fence

• When it fits: scale benefit is high, but one business needs separate evidence or clocks.
• Pros: most of the saving, with regulated data and events separated.
• Cons: more design and governance work.
• Cost and risk: moderate cost, lower regulatory risk.
• My view: the usual answer for the SOC, service desk and core network.

Separate

• When it fits: evidence needs or blast radius make sharing unsafe.
• Pros: clear accountability and simpler audits.
• Cons: duplicated cost and skills.
• Cost and risk: higher cost, lowest cross-business risk.
• My view: right for core lending systems and their privileged access.

Network: segment by risk

Networks in groups often grow by building or by company. A mall network grows floor by floor. A lender's branch network grows branch by branch. The result is segmentation that reflects history, not risk.

From first principles, the question is which systems should never be able to reach each other. Loan systems and guest Wi-Fi are the obvious pair. Less obvious pairs include tenant point-of-sale traffic, building management systems, parking systems and cameras, many of which sit on IP networks managed by facilities vendors.

A useful rule is to treat every connection between a regulated zone and anything else as an exception that needs an owner and a review date. Count those exceptions. A falling number is a better sign of progress than any diagram.

Should your organisation do this now?

• Yes, if any path exists between guest or building networks and lending systems.
• Not yet, if you do not have a current inventory of network zones.
• Instead, first: map zones and the flows between them.
• Measure it by: number of approved cross-zone rules touching regulated systems.

Shared security: one team, separate clocks

A shared security team is often the best use of scarce skills. The risk is that it works to one set of targets while a regulated entity it serves works to another.

Write each regulated business's reporting clock, escalation contact and log-access rights into the internal agreement. Give the regulated entity's declaring authority a direct line into the team, without routing through a group manager. For larger NBFCs, the directions also separate the CISO from the head of IT, so be clear which group roles act for the regulated entity. The practical detail is covered in the six-hour test for NBFC cyber directions.

Vendors: concentration is a group risk

Each business may choose vendors sensibly on its own. Across the group, the same cloud provider, network carrier or managed security partner can quietly become a single point of failure for everything.

List critical services by vendor across the whole group, not by business. Where one vendor supports critical services for a regulated entity and several other businesses, ask what happens if that vendor fails, and whether the regulated entity has the contractual rights it needs on its own.

Should your organisation do this now?

• Yes, if vendor contracts are negotiated separately by each business.
• Not yet, if there is no group-wide list of critical services.
• Instead, first: build the list with vendor, business and criticality.
• Measure it by: number of vendors supporting critical services in more than one business.

State each decision in money

Sharing decisions are usually made on cost and defended on principle. I prefer to state them the other way round: as entries with a cost, a risk and an owner.

That is the idea behind the Architecture P&L: stating architecture decisions as entries in a profit and loss account, so that technical choices carry an owner and a number. A shared SOC then appears as a saving against separate provision, a cost for ring-fencing, and a named risk owner, rather than as a line on an organisation chart.

It also supports a position I hold firmly: governance responsibility has to be balanced against growth targets. A sharing decision that saves money but slows the regulated business's ability to prove compliance is not a saving. A separation that doubles cost for no measurable risk reduction is not governance.

Before you approve it

Checklist:

• Sharing decision recorded for every group technology service.
• Evidence and clock requirements listed for each regulated business.
• Internal agreements updated with those requirements.
• Network zones mapped with cross-zone rules owned and reviewed.
• Group-wide list of critical services by vendor.
• Cost, risk and owner stated for each sharing decision.

Questions to ask:

• Your team: which shared services handle regulated data or events today?
• Your team: how many network paths connect regulated systems to anything else?
• Your group SOC: what is your written escalation time to each regulated entity?
• Your vendors: which of our businesses depend on you for critical services?
• Your compliance head: how does the regulator treat services provided by group companies?
• Your board: what does ring-fencing cost, and what risk does it remove?

How to measure it

• Documented sharing decisions. Share of group services with a recorded decision and owner. Baseline: service catalogue. Owner: group CTO. Review: quarterly. Leading.
• Cross-zone exceptions. Approved rules connecting regulated systems to other zones. Baseline: first network map. Owner: network lead. Review: monthly. Leading.
• Clock coverage. Share of internal agreements carrying regulated clocks and log access. Baseline: agreement review. Owner: group IT governance. Review: quarterly. Leading.
• Vendor concentration. Vendors supporting critical services in more than one business. Baseline: first list. Owner: procurement. Review: half-yearly. Leading.
• Shared-service incidents affecting regulated entities. Count and impact. Baseline: last 12 months. Owner: CISO. Review: quarterly. Lagging.
• Net saving after ring-fence. Shared cost versus separate provision. Baseline: current budgets. Owner: CFO. Review: annually. Lagging.

Mistakes that cost the most

Deciding sharing once, at group level

Services differ too much for one answer.

• Why it happens: shared services are set up as a single programme.
• Prevention: decide service by service.
• Early warning: one sharing policy covering every service.

Letting history define network zones

Old segmentation hides new risks.

• Why it happens: networks grow by site, not by risk.
• Prevention: redesign zones around what must never connect.
• Early warning: facilities devices on the same segment as office systems.

Informal internal service levels

Internal teams are rarely held to written clocks.

• Why it happens: colleagues trust each other.
• Prevention: written agreements with regulated requirements.
• Early warning: regulated entities learning of incidents late.

Counting only the saving

Ring-fencing and evidence costs are left out.

• Why it happens: the original business case predates the regulation.
• Prevention: restate the case with current obligations.
• Early warning: unplanned spend on audit remediation.

Missing group-wide vendor risk

Each business looks fine; the group is exposed.

• Why it happens: contracts are managed locally.
• Prevention: one list of critical services by vendor.
• Early warning: the same vendor named in several business continuity plans.

Frequently asked questions

Should a diversified group share IT services?

Often, yes, for cost and skills. Decide service by service, and let the strictest regulated user set the evidence standard for any service it depends on.

What is ring-fencing in shared IT?

Keeping a shared service but separating a regulated business's data, events, access and reporting clocks within it, so that the service can meet that business's obligations.

Do RBI's NBFC cyber directions cover group service providers?

The directions set requirements for outsourced IT services and third-party arrangements. How they apply to services from group companies should be confirmed with compliance. Governing internal services with the same rigour is a sensible default.

How should a group segment its network?

By risk. Identify which systems must never reach each other, such as lending systems and guest Wi-Fi, and treat every connection into a regulated zone as an owned, reviewed exception.

What is vendor concentration risk?

The risk that one vendor's failure affects many critical services at once. In groups, it often builds up across businesses that each chose the same vendor independently.

What is the Architecture P&L?

A method for stating enterprise architecture decisions as entries in a profit and loss account, so that technical choices carry an owner and a number.

Can one CISO serve several group companies?

That depends on each entity's regulation. For larger NBFCs, RBI's directions set specific reporting lines and independence for the CISO. Check the requirements for each regulated entity.

How often should sharing decisions be reviewed?

At least annually, and whenever a business enters a new regulated activity or a major regulation changes.

What to do next

List every group technology service and record a share, ring-fence or separate decision with an owner. Then read the digital transformation topic page, and the related piece on DPDP compliance for malls and retail.

Sources

• Reserve Bank of India, Non-Banking Financial Companies – Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026, 31 July 2026. rbi.org.in
• Press Information Bureau, DPDP Rules, 2025 notified, November 2025. pib.gov.in

Last reviewed: 15 September 2026.

Views are my own and do not represent my employer.