Trusted Boundaries: The Forgotten Foundation of a Credible ISMS

Why ISO 27001 Scope Is No Longer Just an Organizational Statement

By Eckhart Mehler for CISOsCISO — a perspective on cybersecurity leadership, governance and the decisions that determine whether organizations retain control.

Most organizations can describe the scope of their ISMS.

At least on paper.

They can name the business units included.
They can list the countries in scope.
They can point to central IT services, cloud environments, core processes, certificates, policies and management reviews.

But when asked a more difficult question, many struggle:

Where exactly does trust begin — and where does it end?

That question is becoming one of the most important questions in information security governance.

Not because ISO/IEC 27001 suddenly requires a fashionable new architecture term.

But because modern organizations no longer operate inside neat perimeters.

They operate through cloud platforms, SaaS services, managed devices, unmanaged networks, external identities, APIs, contractors, AI agents, mobile access, global project sites and increasingly autonomous digital workflows.

In that environment, an ISMS scope that only says “these processes are included” or “these locations are included” is no longer enough.

A credible ISMS must explain something more fundamental:

Which parts of the organization’s information processing environment are actually controlled, trusted and governed — and which parts are not?

That is the role of trusted boundaries.

Trusted Boundaries Are Not Just Network Boundaries

The term “trusted boundary” is often misunderstood.

Many still think of it as a network concept: inside the firewall is trusted, outside the firewall is untrusted.

That model is largely obsolete.

The firewall still matters. Network segmentation still matters. Secure connectivity still matters.

But in cloud-based, identity-driven and globally distributed organizations, trust is no longer created by network location alone.

A user may be inside a corporate office but using an unmanaged device.
A system may be inside a cloud tenant but connected to an unreviewed third-party API.
A business process may be centrally defined but executed through local shadow IT.
An AI agent may operate inside an approved platform but have access to email, documents, calendars and business actions that were never part of the original risk assessment.

In all these cases, the old question — “Is it inside our network?” — is almost useless.

The better question is:

Is it inside our trusted boundary?

And that means:

• Is the identity known, managed and governed?
• Is the device controlled?
• Is the application approved?
• Is the data flow understood?
• Is the access logged and monitored?
• Is the responsibility clear?
• Is the risk accepted?
• Is the control environment verifiable?

A trusted boundary is therefore not a cable, a VLAN or a firewall rule.

It is a security, governance and accountability boundary.

It defines where the organization can reasonably claim that information security is actively controlled.

The CISO Problem: Scope Without Trust Is an Illusion

ISO/IEC 27001 requires organizations to define the scope of the ISMS.

That sounds straightforward.

But in practice, ISMS scope is one of the most sensitive governance decisions a CISO will ever deal with.

Because scope determines what is governed.
What is audited.
What is certified.
What is reported.
What is excluded.
And, sometimes, what is conveniently ignored.

A weak scope creates a dangerous illusion.

It allows an organization to say:

“We are ISO 27001 certified.”

But the more important question is:

Certified for what — and under which trust assumptions?

If the organization’s core business processes depend on local networks, unmanaged endpoints, third-party SaaS tools, external administrators, global project sites or uncontrolled identities, then the scope cannot simply ignore those dependencies.

It may exclude them from certification.

But it cannot exclude them from risk.

That is where trusted boundaries become essential.

They force the organization to distinguish between:

What is inside the formal ISMS scope
and
what the scoped environment depends on in reality.

This distinction is critical.

Because many serious security failures do not begin inside the beautifully documented ISMS.

They begin at the boundary.

At the supplier interface.
At the unmanaged endpoint.
At the local admin account.
At the unreviewed SaaS service.
At the identity federation.
At the API integration.
At the AI connector.
At the “temporary” exception that became permanent.

The boundary is where the ISMS is tested.

Not the certificate.

A Trusted Boundary Defines Where Control Is Real

From a CISO perspective, a trusted boundary should answer a simple but uncomfortable question:

Where can we prove that our security controls actually apply?

Not where we hope they apply.
Not where policy says they should apply.
Not where organizational charts suggest responsibility exists.

But where security control can be demonstrated.

That includes:

• managed identities
• governed access rights
• multi-factor authentication
• conditional access
• endpoint management
• endpoint detection and response
• encryption
• patch management
• vulnerability management
• logging and monitoring
• incident response coverage
• backup and recovery
• supplier controls
• change management
• risk acceptance
• policy enforcement
• audit evidence

A trusted boundary is the line around the environment where these controls are not just written down, but operationally effective.

Outside that boundary, the organization may still operate.

But it should not pretend that the same trust level exists.

This is especially important for international organizations.

A global organization may have employees, offices, projects and partners in dozens or hundreds of locations. But that does not mean every local environment has the same security maturity, tooling, monitoring, connectivity, contracts or operational discipline.

In such cases, a modern ISMS may deliberately define its trusted boundary around centrally controlled core processes, managed clients, approved applications, centralized identity services and monitored security controls.

Local networks may then be treated as access infrastructure — not as fully trusted environments.

That can be a legitimate scoping decision.

But only if it is explicit, risk-based and supported by compensating controls.

The Difference Between “In Scope” and “Trusted”

One of the most important distinctions in ISMS design is the difference between being “in scope” and being “trusted.”

Something can be in scope but not fully trusted.

For example, a local office may be included in the organizational scope because employees there use central systems. But its local network, printers, unmanaged devices or ad-hoc storage may not be trusted components of the controlled environment.

Something can also be outside the certification scope but still security-relevant.

For example, a third-party SaaS platform may not be part of the certified ISMS scope. But if it processes confidential data, connects to identity systems or supports a critical business process, it is absolutely relevant to ISMS risk management.

This is where many organizations make a subtle but dangerous mistake.

They treat scope exclusions as risk exclusions.

They are not.

A scope exclusion is a certification and management boundary.

It does not remove the organization’s dependency on the excluded environment.

It does not remove legal responsibility.

It does not remove business impact.

It does not remove incident exposure.

It only means that the excluded environment is not governed to the same depth within the ISMS.

That decision must be visible, justified and risk-managed.

A trusted boundary makes this transparent.

What a Trusted Boundary Must Describe

A good trusted boundary description is not a diagram alone.

It is also not a generic paragraph in a scope document.

It must be specific enough that management, auditors, architects, risk owners and security teams can understand what is being claimed.

A trusted boundary should describe at least nine elements.

First, it must define the purpose of the boundary.

Why is this boundary being drawn?
Is it to separate controlled core processes from local access infrastructure?
Is it to distinguish managed devices from unmanaged devices?
Is it to define which cloud services are approved?
Is it to clarify what is covered by certification?

Second, it must define what lies inside the boundary.

This includes processes, systems, applications, identities, endpoints, data stores, cloud environments, security controls and operational responsibilities.

Third, it must define what lies outside the boundary.

This is often the more important part.

Unmanaged networks.
Private devices.
Shadow IT.
Unapproved SaaS tools.
Local storage.
Uncontrolled identities.
External platforms.
Non-accredited applications.
Unreviewed AI tools.
Supplier systems.

If these exclusions are not named, they will later be misunderstood.

Fourth, it must describe the trust assumptions.

Why is the environment considered trusted?
Because it is centrally managed?
Because devices are enrolled?
Because identities are governed?
Because access is conditional?
Because logs are monitored?
Because contractual controls exist?

Trust must not be implied.

It must be explained.

Fifth, it must describe the controls that create trust.

These are the mechanisms that turn an abstract boundary into a defensible security position.

Sixth, it must describe the interfaces crossing the boundary.

Every connection to another system, supplier, network, tenant, SaaS service, AI platform or administrative domain is a potential boundary crossing.

Seventh, it must describe residual risks.

No boundary is perfect.

There will be dependency risks, monitoring gaps, operational exceptions, local constraints, legal limitations, supplier limitations or technical debt.

These must be visible.

Eighth, it must define accountability.

Who owns the boundary?
Who approves changes?
Who monitors violations?
Who accepts residual risk?
Who decides whether a new service is inside or outside?

Finally, it must describe evidence.

A trusted boundary that cannot be evidenced is only a statement of belief.

Evidence may include architecture diagrams, asset inventories, identity records, endpoint compliance data, logging coverage, risk assessments, supplier assessments, configuration baselines, audit reports, exceptions, management approvals and incident response records.

Trusted Boundaries and ISO 27001 Scope

Trusted boundaries matter directly to ISO/IEC 27001 scope definition.

The scope of the ISMS should not only say what is included.

It should also explain the logic of inclusion and exclusion.

A mature scope statement should answer:

• Which business processes are covered?
• Which information assets are covered?
• Which locations are covered?
• Which technologies are covered?
• Which internal and external interfaces exist?
• Which dependencies are material?
• Which parts are excluded?
• Why are they excluded?
• What risks arise from the exclusion?
• Which controls protect the boundary?

For a modern organization, the ISMS scope should not be a flat organizational map.

It should be an architecture of control.

A simple example:

The ISMS may cover central core processes and the systems that support them. These processes may be accessed globally. However, not every country office, local network or project location is treated as a fully controlled ISMS site. Instead, the trusted boundary is defined through centrally managed clients, central identity and access management, secure connectivity, endpoint protection, encryption, monitoring and approved applications.

That is a much stronger statement than simply saying:

“The ISMS covers central services.”

It explains why the scope is defensible.

It also explains where the risks remain.

The Modern Boundary Is Identity- and Device-Centric

In many organizations, the most important trusted boundary is no longer the physical site.

It is the combination of identity, device, application and data flow.

A managed user on a compliant device using an approved application through conditional access may be inside the trusted boundary — even when working from a hotel, airport, project site or home office.

An unmanaged device inside a corporate building may be outside the trusted boundary — even when connected to the local office network.

This is a major shift in how security leadership must think.

Trust is no longer primarily location-based.

It is control-based.

That means a trusted boundary often depends on:

• central identity governance
• strong authentication
• device compliance
• endpoint security
• data classification
• application approval
• secure access policies
• least privilege
• privileged access management
• logging and monitoring
• policy enforcement

The CISO should therefore be very careful with any scope statement that overemphasizes buildings, countries or networks while underemphasizing identities, devices and data flows.

In a cloud-first world, that is usually the wrong emphasis.

AI Agents Make Trusted Boundaries Even More Important

Artificial intelligence makes the trusted boundary question more urgent.

Traditional systems waited for users to act.

AI-enabled systems increasingly assist, recommend, summarize, retrieve, classify, draft, decide, trigger workflows and connect to tools.

Once AI agents are introduced, the boundary is no longer only about where data is stored.

It is also about what the agent can access, infer and do.

An AI agent connected to email, documents, calendars, ticketing systems, HR workflows or procurement platforms may cross several trust boundaries at once.

It may access personal data.
It may combine information across contexts.
It may act with delegated permissions.
It may use connectors to reach systems not originally assessed together.
It may produce outputs that humans treat as decisions.
It may trigger business actions.

From an ISMS perspective, this raises serious boundary questions:

• Is the AI platform inside the trusted boundary?
• Are the connected systems inside the same boundary?
• Are the models, plugins and agents approved?
• Are prompts, outputs and logs governed?
• Are permissions inherited from users or assigned separately?
• Are agent identities managed like other identities?
• Are actions reversible?
• Are data flows documented?
• Are third-party model providers involved?
• Are outputs used for decisions, assessments or approvals?

AI governance that does not address trusted boundaries will become too narrow.

It will focus on acceptable use while missing the architecture of control.

For CISOs, the central question is not whether an AI system is “allowed.”

The central question is:

Which trust boundaries does it cross — and who has accepted that risk?

Trusted Boundaries Must Include Suppliers and Cloud Platforms

Another common mistake is to treat cloud and supplier environments as automatically trusted because they are professionally operated.

That is not enough.

A hyperscaler may be secure.

A SaaS provider may have certifications.

A managed service provider may have excellent processes.

But the organization still needs to understand the trust relationship.

What is the provider responsible for?
What remains the customer’s responsibility?
Which logs are available?
Where is data processed?
Who can administer the environment?
Which subcontractors are involved?
How are incidents reported?
How are backups handled?
How is exit managed?
Which legal jurisdictions apply?
Which encryption and key management models are used?

A supplier can be inside the extended control environment.

But it should never be inside the trusted boundary by assumption.

Trust in suppliers must be constructed through due diligence, contracts, technical controls, monitoring, integration architecture, audit rights, incident obligations and risk acceptance.

Supplier trust is not a logo.

It is a control model.

The Boundary Is Where Governance Must Become Concrete

Trusted boundaries force governance to become operational.

They expose the gap between policy and reality.

A policy may say that only approved applications may process confidential information.

But the trusted boundary asks:

How is that enforced?
How are applications approved?
How is shadow IT detected?
How are exceptions handled?
How are data exports controlled?
How are SaaS integrations reviewed?
How is user behavior monitored?
How is non-compliance escalated?

A policy may say that access is based on least privilege.

But the trusted boundary asks:

Which identity system is authoritative?
How are privileged roles assigned?
How often are access rights reviewed?
How are service accounts governed?
How are machine identities handled?
How are external users removed?

A policy may say that endpoints are secured.

But the trusted boundary asks:

Which devices are managed?
Which are only partially managed?
Which are unmanaged?
Which can access sensitive systems?
What happens when a device becomes non-compliant?

This is why trusted boundaries are so valuable.

They convert governance language into control reality.

What CISOs Should Look For

When reviewing an ISMS scope, a CISO should challenge it with practical questions.

Can we explain what is inside the trusted boundary?
Can we explain what is outside?
Can we prove that the included environment is controlled?
Can we prove that exclusions are risk-managed?
Can we identify all boundary crossings?
Can we detect violations?
Can we respond when the boundary fails?
Can management understand the residual risk?

If the answer is no, the scope may still pass a formal review.

But it is not yet a mature security scope.

The strongest ISMS scopes are not the broadest ones.

They are the clearest ones.

They make explicit where the organization has control, where it has dependency, where it has uncertainty and where it has accepted risk.

That clarity is more valuable than a large but vague certification boundary.

A Practical Model for Describing Trusted Boundaries

A useful trusted boundary description can be structured as follows.

1. Boundary Definition

Define the trusted boundary in plain language.

For example:

The trusted boundary of the ISMS consists of all information processing environments, identities, devices, applications, data flows and operational responsibilities that are governed by centrally defined and verifiable security controls.

2. Included Components

Describe what is inside.

This may include:

• core business processes
• approved applications
• managed endpoints
• central identity services
• privileged access management
• cloud tenants
• data repositories
• network services
• logging and monitoring
• backup and recovery services
• security operations processes

3. Excluded Components

Describe what is outside.

This may include:

• unmanaged devices
• local networks not centrally controlled
• non-approved SaaS
• shadow IT
• local storage
• external systems without assessment
• supplier environments outside contractual control
• private accounts
• ungoverned AI tools
• unapproved APIs or connectors

4. Trust-Enabling Controls

Describe why the included environment is trusted.

This should include the technical, organizational and contractual controls that create the trust basis.

5. Boundary Crossings

List the interfaces that cross the boundary.

These are often the most important risk points.

Examples include:

• supplier connections
• SaaS integrations
• identity federation
• remote access
• API gateways
• data exports
• AI connectors
• administrative access
• local infrastructure dependencies

6. Residual Risks

Explain what remains uncertain or only partially controlled.

This is not a weakness.

It is a sign of maturity.

An ISMS that pretends to have no residual boundary risk is usually not credible.

7. Ownership and Evidence

Define who owns the boundary and how it is evidenced.

Without ownership, boundaries decay.

Without evidence, boundaries are declarations.

The Most Common Mistakes

Organizations repeatedly make the same mistakes when defining trusted boundaries.

They define the boundary around the organization chart instead of the control environment.

They assume that corporate ownership equals security control.

They include locations without understanding the local technology stack.

They exclude locations without assessing their dependency on central processes.

They treat cloud platforms as trusted because the provider is certified.

They forget unmanaged endpoints.

They forget service accounts.

They forget APIs.

They forget AI agents.

They forget data exports.

They forget local administrators.

They forget that identity is now often the real perimeter.

Most importantly, they confuse documentation with control.

A trusted boundary is not trusted because it is documented.

It is trusted because controls operate, evidence exists and accountability is clear.

Trusted Boundaries Are a Board-Level Topic

Trusted boundaries may sound technical.

They are not.

They are a board-level governance topic.

Because they define the real limits of organizational control.

A board does not need to understand every firewall rule, conditional access policy or logging connector.

But it does need to understand whether the organization’s critical processes are operating within a controlled environment.

It needs to know where the organization relies on local infrastructure, suppliers, cloud platforms, external administrators, unmanaged devices or AI-enabled workflows.

It needs to know whether the ISMS certificate reflects the real operating model.

It needs to know whether scope exclusions are conscious risk decisions or convenient blind spots.

The CISO’s role is to make these boundaries visible.

Not to create fear.

But to prevent false confidence.

The CISO View

For a CISO, the core message is simple:

A trusted boundary does not describe whom we like, own or contract with. It describes where we can prove that information security is governed, enforced and monitored.

That distinction matters.

Trust is not created by belonging to the organization.
Trust is not created by being on the corporate network.
Trust is not created by using a well-known cloud provider.
Trust is not created by having a certificate.
Trust is not created by policy language.

Trust is created by controlled identities, controlled devices, controlled data flows, controlled applications, controlled suppliers, controlled responsibilities and controlled exceptions.

That is what the ISMS scope must make visible.

And that is what ISO 27001 certification should ultimately support.

Not a decorative boundary around a convenient part of the organization.

But a clear, defensible and risk-based statement of where the organization is actually in control.

In the end, the trusted boundary is where the ISMS becomes honest.

It tells management where control exists.
It tells auditors what is really being governed.
It tells architects what must be protected.
It tells risk owners what they are accepting.
It tells security teams where to monitor.
And it tells the CISO where the organization may already be losing control.

That is why trusted boundaries are not a technical detail.

They are one of the foundations of credible cybersecurity leadership.

Publication Note & Disclaimer
This article reflects my personal professional perspective and does not represent the official policy or position of my employer. Drafting and editorial refinement may have been supported by commercially available AI-assisted tools. The analysis, conclusions and final curation are entirely my own.

For information regarding image credits, copyrights, trademarks and other intellectual property rights, please refer to the Imprint.