When we decided to establish a technology operation in India, there were, naturally, a lot of things to think about.

• Where should we establish it?
• How should we structure it?
• Who should we bring on board?
• What technology would we need?
• How quickly could we become operational?

These are the questions most people would probably ask first. We did too.

But as we worked through the process, we found that some of the more important questions were actually sitting underneath all of these.

What were we legally and regulatorily required to do? How should responsibilities be divided between the local and global organization? How much autonomy should the local team have? What controls should be in place before people and systems became operational? And, perhaps less obviously, how much should we be thinking about the wider Internet environment in which the business would operate?

That changed the way we approached the exercise.

We had initially thought of it as building an operation. In practice, we realized that we were really designing an operating environment.

And that environment had to bring together regulation, governance, security, people, technology and the wider Internet ecosystem.

That experience led us to a fairly simple conclusion: these things should not be designed separately.

Start With the Rules, Not the Recruitment Plan

When a company decides to establish an operation in another country, it is very easy to get focused on the things that are visible.

• We need an office.
• We need people.
• We need systems.
• We need vendors.
• We need to start delivering.

There is a natural pressure to get moving.

Our experience suggested that it was better to pause and ask a more fundamental question first: What are we actually permitted, required and expected to do in this jurisdiction?

In India, that meant working through corporate requirements, taxation and GST, employment considerations, contracts, technology requirements and the various obligations that come with operating across borders.

None of those things were particularly surprising on their own. The complication was that they were connected.

A regulatory requirement could affect the way a process was designed → The process could influence a technology decision → That technology decision could have security implications → A security decision could determine who could access a system, from where and under what circumstances.

Once we looked at it that way, it became clear that treating compliance as a separate workstream would not make much sense.

Compliance Is Easier When It Is Designed Into the Operation

There is a difference between asking: “Are we compliant?” and asking: “How should we design the operation so that compliance is built into the way we work?”

We found the second question much more useful.

So rather than trying to bolt controls onto an already functioning organization, we thought it was better to establish some of the basic boundaries before the operation became busy.

• Who is responsible for what?
• Which decisions can be made locally?
• Which require global oversight?
• What needs to be escalated?
• Which external parties have access to systems or information?
• What happens when something falls outside the normal process?

These are not particularly exciting questions. They are, however, the questions that become very exciting when nobody has answered them and something goes wrong.

We also deliberately avoided creating governance for the sake of governance. It is quite possible to produce a beautifully documented operating manual that nobody has time to read, let alone follow.

The objective, at least for us, was simpler. People should know what they are responsible for, what they are allowed to decide, and when they need to stop and ask.

That creates clarity. And clarity creates speed.

Security Should Be Designed Before the Operation Gets Busy

Once the basic operating structure was clear, the next question became more practical:

How do you give people enough freedom to move quickly without creating unnecessary security exposure?

This is particularly relevant in a distributed organization. People may be working remotely. Teams may be spread across countries. Systems may be hosted in different environments. Specialist suppliers may need access to particular systems.

We could have responded by putting layers of approval around everything. We could also have gone in the other direction and given people broad access because it was easier. Neither seemed sensible.

Our approach was to start with a fairly simple principle: Give people the access they need to perform their responsibility, and no more than that. It sounds almost too obvious.

But starting with that principle makes a surprising number of subsequent decisions easier. If somebody’s responsibility changes, their access should change.

If a supplier needs temporary access, there should be a reason for it and a way of controlling it. If somebody leaves the organization, access should not remain simply because nobody remembered to remove it.

The advantage of doing this while establishing a new operation is that you do not have years of legacy permissions to clean up. There is nothing particularly clever about that.

It is simply easier to build a sensible foundation than to repair a complicated one later.

Remote Does Not Have to Mean Uncontrolled

One of the other decisions we made was to give capable people considerable operational autonomy.

That was partly a productivity decision. It was also a management decision. And, interestingly, it had implications for security.

We did not want management to become a bottleneck for routine decisions. At the same time, we did not want autonomy to mean that management had no idea what was happening.

That led us back to something I have used in different forms throughout my career: Management by exception.

The idea is fairly straightforward. If something is operating as expected, let it operate. If something falls outside the expected pattern, make the exception visible and deal with it.

That sounds simple, but it requires a certain amount of discipline and trust.

People need to understand the expected way of working. Managers need sufficient visibility. And the organization needs a clear mechanism for dealing with exceptions. The alternative is often micromanagement disguised as control.

Every decision goes upwards. Every unusual event becomes a meeting. People wait for approvals. Managers become the human equivalent of a network bottleneck.

That is not good operational design. Nor is it particularly good security. If everything requires manual intervention, eventually people start finding ways around the process.

A well-designed operating model should make the secure and sensible way of working the easiest way of working.

The Security Conversation Is Ultimately About People

It is tempting to make cybersecurity a discussion about technology.

Identity management. Endpoint protection. Encryption. Monitoring. Network controls.

All of these are important.

But sooner or later, a person is going to receive an unusual request. Someone will ask for access they do not normally require. A supplier will send an unexpected document. An employee will notice something that does not look right.

At that point, technology can only take us so far. The person has to make a decision.

So one of the things we considered important was creating an environment in which people felt able to question something that did not look right.

Would someone feel comfortable saying, “This doesn’t seem normal”? Would they know who to approach? Would raising the issue be treated as responsible behaviour or as an inconvenience?

That last question mattered more than it appeared. If people are encouraged to keep things moving at all costs, security eventually loses. A security culture therefore cannot just be a policy document or an annual training exercise.

It has to be part of how people are expected to work. In our experience, trust and control are not necessarily opposites.

The better combination is trust supported by visibility, clear boundaries and accountability.

But Where Does Internet Governance Come Into All This?

This was the part of the exercise that I found particularly interesting.

If regulation establishes some of the boundaries within which an organization operates, and cybersecurity protects the organization within those boundaries, where does Internet governance fit?

At first, it might appear to be a completely different subject. Only that it isn’t.

Any organization that depends upon the Internet is operating within a much larger ecosystem. There are technical standards, protocols, domain names, IP addressing, infrastructure operators, registries, regulators, policy institutions and national jurisdictions.

Most businesses do not think about these things every morning. They shouldn’t have to. But they depend upon them every morning.

We type a domain name into a browser without thinking about the DNS infrastructure that makes the name resolvable.

We send information across networks without thinking about the standards that allow different networks and systems to interoperate.

We build digital services without necessarily considering the institutions and processes that sit behind many of the Internet resources on which those services depend.

The fact that these things are largely invisible is actually a sign that the underlying system is working. But invisible does not mean unimportant.

The Internet Is Infrastructure, but It Is Also Governance

This raises a question that I think technology leaders should ask more often:

Who governs the environment on which my digital business depends? There is no single answer. Different parts of the Internet involve different technical, governmental, commercial and multistakeholder institutions and processes.

And increasingly, these areas overlap. A business may never attend an Internet governance meeting. It may never participate in a standards process. It may never have a direct conversation with a registry or infrastructure operator. Yet decisions made within these ecosystems can eventually affect the business.

That is why I think Internet governance deserves a place in the thinking of technology and business leaders. I am not suggesting that every CEO needs to become an Internet governance specialist. That would be neither realistic nor particularly useful.

But if a company’s business depends fundamentally on digital infrastructure, it should at least understand the environment in which that infrastructure operates.

The questions become especially relevant when we start talking about cybersecurity, privacy, digital sovereignty, resilience, cross-border data flows and the increasing involvement of governments in the digital environment.

These are no longer purely technical questions. Nor are they purely policy questions - They are increasingly business questions.

So How Should a Modern Cross-Border Operation Actually Be Designed?

Looking back at our experience, I would now think about the problem as five connected layers.

1. REGULATORY ARCHITECTURE – Understand the legal, regulatory and contractual environment before making major operating decisions. Don’t ask compliance to clean up decisions that have already been made. Give compliance a seat at the design table.
2. GOVERNANCE ARCHITECTURE – Decide early who has authority, who is accountable and what constitutes an exception. People should not have to discover the organization’s decision-making structure during a crisis.
3. SECURITY ARCHITECTURE – Build identity, access, monitoring, resilience and incident response into the operation from the beginning. Do not assume security can be added once the business is already running.
4. OPERATING ARCHITECTURE – Give capable people room to execute. But make the boundaries and escalation mechanisms clear enough that autonomy does not become unmanaged risk.
5. INTERNET ARCHITECTURE – Understand the wider technical, institutional and policy environment on which the digital operation depends. You do not need to understand every layer in detail. You do need to know where your dependencies are.

The Real Test Is What Happens When Something Goes Wrong

There is one question I would now ask before declaring a new digital operation “ready.”

Not:
Does everything work when everything goes right?

But:
What happens when something doesn’t?

• A supplier suddenly becomes unavailable.
• Someone needs urgent access to a system.
• A key employee is not available.
• A security incident occurs.
• A regulatory requirement changes.
• A technology dependency fails.
• A decision has to be made by someone who was not involved in designing the original process.

What happens then?

If the answer is:

“We need to find the one person who knows how this works.” Then there is probably still some work to do. The organization has a dependency rather than an operating model. This is something that becomes particularly obvious during a crisis.

The organizations that respond well are generally not the ones with the largest number of policies. They are the ones where people understand their responsibilities, decision rights, escalation paths and dependencies before the crisis occurs. That is what resilience looks like in practice. We did this in our own way. It was painful initially, but we started seeing the benefits quite early.

Speed and Discipline Can Coexist

Perhaps the most useful thing we learned from the exercise was that speed and discipline do not have to be opposing forces. They often become opposing forces when discipline is implemented as bureaucracy.

Good architecture is different. Clear regulatory boundaries reduce uncertainty. Clear decision rights reduce unnecessary escalation. Good security design allows people to work with confidence. A sensible exception model allows management to focus on things that actually require management attention.

And understanding the wider Internet environment reduces the likelihood of being surprised by something that was actually visible to the ecosystem long before it became visible to the business.

We therefore found ourselves thinking less about how to control the operation and more about how to design it so that the right behaviour became the natural behaviour.

That is a subtle difference. But it is an important one.

Build It In, Rather Than Bolt It On

If I had to reduce the entire experience to one lesson, it would be this:

Do not build the organization first and then try to make it compliant, secure and governable.

Build those characteristics into it from the beginning. Technology will change. People will change. Threats will change. Regulations will change. The Internet itself will continue to evolve.

So the operating model has to be capable of evolving as well. That does not mean trying to predict every future development.

It means building an organization that can recognize change, understand its implications and respond without having to reinvent itself every time something moves.

For me, that is where the connection between regulation, cybersecurity and Internet governance becomes much clearer.

They may belong to different professional disciplines. They may involve different institutions and communities.

But from the perspective of someone actually trying to build and operate a digital enterprise from the ground up, they are deeply connected.

Regulation establishes the boundaries. Governance establishes how decisions are made. Security protects the operation. People and processes make it work. The Internet provides the environment in which all of it ultimately exists.

The objective is not to operate without constraints. That is impractical and not really an option.

The objective is to understand the constraints, design intelligently around them and give people enough clarity and autonomy to operate effectively within them so as to thrive.

That, in my view, is what a resilient digital operation should look like.