Zero Trust for GCC Enterprises: Where to Start

Start with the access decision

Zero Trust means making access decisions around the identity, context and resource involved, rather than assuming that a request is safe because it comes from inside the company network. A practical starting point is one important application: understand who and what can reach it, define the access each role needs, and test those rules before extending the approach.

For an enterprise operating across offices, cloud services and external partners, this creates a useful question: can the organization explain why a particular person or software service can access a particular piece of business information?

The answer needs to hold when a contractor changes role, a device becomes non-compliant or a service account is no longer required.

What changes when an enterprise adopts Zero Trust?

NIST SP 800-207 describes an architecture that does not grant implicit trust solely because of network location or asset ownership. Authentication and authorization are evaluated before establishing access to a resource.

• NIST: Zero Trust Architecture

That changes the starting point of the design. Being on the office network is insufficient reason to access payroll. A successful sign-in does not, by itself, justify permission to export every customer record.

Network controls still have a role. Zero Trust asks how identity, device context, application permissions and information protection work together around an access decision. It is a design approach that can involve several technologies, not a single product purchase.

Choose a bounded business application first

Start with an application whose owner can explain both the information at risk and the work that must remain possible. A customer portal, finance application or remote maintenance service may be suitable, depending on the organization’s exposure and available controls.

For a hypothetical GCC group with a shared finance application, the first boundary could be contractor access to invoice-support records. Contractors need access to a defined set of documents; they do not need unrestricted access to the wider finance environment.

Before changing a policy, document the actual users, supporting services, device types and routes into the application. Include scheduled integrations and support tools. A control that protects the visible sign-in page but misses an old integration path leaves part of the access problem unresolved.

NCSC’s architecture principles emphasize knowing users, services, devices and data, and using their identities and context to inform policies. That inventory is a design input, not administrative paperwork.

• NCSC: Zero trust architecture design principles

Review five connected areas

CISA’s maturity model organizes progress across identity, devices, networks, applications and workloads, and data. Although developed for US federal agencies, CISA also encourages other organizations to consider the guidance. The questions below are Bridges’ practical adaptation for an initial application review.

• CISA: Zero Trust Maturity Model update

Use these areas to find gaps across the same workflow. They are not five separate procurement projects, and an enterprise may have different levels of maturity within each one.

Make the access decision visible

A simplified view follows a request through policy evaluation, enforcement and observation. The diagram below is an editorial simplification of the policy-decision and enforcement concepts in NIST SP 800-207, section 3; it is not a deployment blueprint.

• NIST SP 800-207, section 3

In the contractor example, an active contract and valid identity might support access to the assigned invoice records from an approved device. A request to change payment details would require different permissions and the business’s separate approval process.

If the engagement ends, the team should be able to remove access and verify that the change has taken effect. If device information is missing, the policy should define a restricted route or denial rather than quietly assuming the device is healthy.

These are proposed controls for the scenario. The exact policy depends on the application, information sensitivity and operating needs.

Pilot the control and the support process together

Changing access can interrupt legitimate work. Include the application owner, identity team, service desk and a representative user group in the pilot.

Begin with a small set of users and well-understood actions. Where tooling supports it, observe what a proposed rule would do before enforcing it. Then test the permitted and rejected cases deliberately: a valid user, an expired contractor, a changed device, an excessive permission request and an unavailable dependency.

Agree how people obtain support and how approved emergency access works. Exceptional access needs an owner, an expiry and a review trail. A permanent bypass undermines the purpose of the control.

Test recovery from policy mistakes as well as blocking behaviour. Keep the rollback decision explicit and protect the logs needed to understand what occurred. A security control should have an operating owner after the project team leaves.

Measure control effectiveness and usable access

For the pilot, agree a small set of measures with consistent definitions:

• Unowned access: accounts or integrations in scope without a current accountable owner.
• Revocation time: elapsed time between an approved removal request and verified loss of access.
• Legitimate-access failures: valid tasks blocked by the new policy, with their causes and resolution time.
• Exception age: temporary access that remains open beyond its agreed expiry.

These are proposed review measures, not benchmark targets or a promise of fewer incidents. Look at the underlying cases before interpreting an improving percentage. Removing a group of users from the pilot, for example, can make a failure rate look better without fixing the rule.

Expand when the team can explain the policy, demonstrate the intended restrictions and support the people using it. NIST’s implementation practice guide provides concrete example architectures that can inform the next design stage. They are reference implementations to evaluate against your environment, not a required vendor stack.

• NIST: Implementing a Zero Trust Architecture

What should GCC leaders decide before rollout?

Set the scope of the first application, name its business and technical owners, and agree what evidence will justify expansion. Bring the organization’s applicable requirements into that design: the compliance owner should confirm obligations for the relevant entity, sector, information and jurisdictions before access or hosting arrangements change. The international frameworks cited here are not presented as a GCC-wide legal mandate.

The most useful first deliverable is an access map and a tested policy for an important business workflow. That gives the next investment a concrete foundation.

Bridges’ Cybersecurity and Managed IT & Cloud Operations services connect security design with ongoing operations. Talk to us about the application or access risk you want to address first.

• Cybersecurity
• Managed IT & Cloud Operations
• Talk to us about the application or access risk you want to address first

About this article

Developed from Mohamed Elnahas’s original Zero Trust article, with updated source checks and a focused application-review approach for Bridges. The contractor scenario and proposed measures are illustrative, not reported client results.

• original Zero Trust article