Implementing a Zero Trust Strategy: Roles, Responsibilities and Metrics

Anyone who today wants to implement a Zero-Trust strategy will quickly notice: the real hurdle is seldom a missing tool, but missing clarity. Zero Trust is an operating model for identities, devices, networks, data and applications. It shifts decisions from “inside is trusted” to “every access is continuously verified”. That reaches deep into processes: permissions, change management, incident response, audit evidence and, not least, the user experience.

To prevent a Zero-Trust initiative from ending up as a collection of isolated security measures, three things are required that are often missing in day-to-day operations: (1) a roles and responsibilities model that binds IT, security and business units, (2) actionable policies that can be integrated into operations and projects, and (3) metrics that make progress and risk transparent without creating a reporting monster.

This article delivers exactly that: a practical governance structure, a RACI logic for critical building blocks and a KPI set that is reliable for both IT management and compliance and audit. Technical terms are briefly contextualized so decision-makers and operations owners speak the same language.

Implementing a Zero-Trust strategy: What Zero Trust means in practice (and what it doesn’t)

Zero Trust is often misunderstood as “everything is forbidden until it is explicitly allowed”. In practice it is not about maximum RESTrictiveness, but about controlled trust with a verifiable justification. The core principles can be reduced to three operational guidelines:

• Explicitly verify: Access is bound to identity, device state, context (location, time, risk) and resource. Typical mechanisms are MFA (Multi-Factor Authentication) and Conditional Access (context-based access rules).
• Least Privilege: Everyone is granted only the permissions they need for the task, and only for as long as necessary. This applies to business users as well as admin accounts and service accounts.
• Assume breach: Plan as if an attacker is already in the network. This implies segmentation, comprehensive logging and fast response.

What Zero Trust is not: a single product, a pure network project or a single IAM measure. A “Zero Trust architecture” is more of a target state that is implemented step by step across multiple domains: identity (IAM), privileged accounts (PAM), endpoints (Endpoint Management/EDR), network access (ZTA/Proxy/VPN replacement), data access (DLP/Classification) and observability (Logging/SIEM).

Why roles and responsibilities determine success or stagnation

Zero Trust creates many new „small decisions“: May a service account without MFA still access production databases? What device requirements apply to external service providers? Which exceptions are permissible, for how long, and who approves them? If these decisions are not anchored in a clear model, three typical failure patterns emerge:

• Shadow exceptions: Teams bypass policies because processes are too slow or nobody is responsible. Result: real risk increases, auditability decreases.
• Overblocking: Security enforces rigid rules without operational feedback. Result: productive work suffers, projects are delayed, pressure mounts to disable controls.
• Measurement blindness: A lot is being „done“, but nobody can say whether risk is decreasing or only effort is increasing.

The countermeasure is classic governance, but tailored specifically to Zero Trust: defined roles, RACI per control component and a lean KPI set that comes directly from the systems (Identity Provider, Endpoint Management, SIEM, Ticketing).

Role model for implementing a Zero-Trust strategy

Depending on company size, roles are individuals or teams. Important: accountability is not delegable, tasks are. The following roles have proven effective in practice:

Executive Sponsor (CIO/IT leadership or management with an IT remit)

Secures budget and priority, resolves conflicts between security and the business, and consciously accepts risks (Risk Acceptance). Without a sponsor, exceptions become the norm.

CISO / Information Security Responsible

Responsible for the security target state, the policy logic and the risk model. Important: not to „operate everything themselves“, but to make requirements verifiable and govern via metrics.

Zero-Trust Program Lead (Security/IT jointly)

Orchestrates the roadmap, dependencies and rollout waves. This role is central to prioritization: which systems first, which controls to what depth, and which quick wins immediately relieve operations (e.g., admin MFA, device compliance).

IAM Owner (Identity and Access Management)

IAM covers identities, roles, groups, authentication and provisioning (Joiner/Mover/Leaver). The IAM owner ensures that permissions are traceable and access is not granted „by email“.

PAM Owner (Privileged Access Management)

PAM manages privileged accounts: admin access, break-glass accounts, credential vaulting, session recording. This role is critical because privileges are attackers‘ most common shortcut.

Endpoint Management / Workplace Owner

Responsible for device state (patch level, encryption, EDR agent, secure boot) and thus the basis for Conditional Access. Without clean device compliance, Zero Trust quickly becomes „MFA-only“.

Network and Platform Operations

Implements segmentation, access paths and platform controls (e.g., ZTNA gateways, proxy, firewall rules, Cloud Security Controls). Important: documented standard paths instead of individual special routes per application.

Application Owner / System Responsible

Functionally and technically responsible for applications and data. Decides on data classification, integration patterns, service accounts and implementation windows. Without an application owner, clean exception rules are hardly possible.

Compliance / Data Protection / Audit Liaison

translates regulatory requirements (e.g. NIS2 as EU directive for cybersecurity, ISO 27001 as a management system standard) into verifiable evidence requirements: which logs, which approvals, which policy versions are presented in the audit?

RACI matrix: who decides, who implements, who provides evidence?

A RACI matrix (Responsible, Accountable, Consulted, Informed) prevents everyone from being „somehow involved.“ Below is a practical configuration for typical Zero Trust components. Adapt role names to your organisation, not the logic.

RACI (Short form, exemplary)

Component / Decision                     R            A            C                          I
-----------------------------------------------------------------------------------------------------------
Zero-Trust-Policy-Set (core rules)       CISO         Sponsor      IT Operations, Compliance     Business units
MFA-Standard (who, when, exceptions)     IAM-Owner     CISO         Service Desk, Compliance     All users
Conditional Access (device, location, risk)IAM-Owner     CISO         Endpoint-Owner, SOC          IT Management
PAM scope (admins, third parties, emergency)  PAM-Owner     CISO         IT Operations, Audit            Sponsor
Device-Compliance-Standards              Endpoint-OwnerIT Management   CISO, Works Council/HR         Users
Segmentation / access paths              Network Operations IT Management   CISO, App Owner              SOC
Logging/SIEM-Use-Cases & Retention          SOC/SIEM-OwnerCISO         Data Protection, IT Operations      Audit
Exception process (Risk Acceptance)      Program Lead  Sponsor      CISO, Compliance, App Owner  Audit
On-/Offboarding (Joiner/Mover/Leaver)    IAM-Owner     IT Management   HR, Business unit              CISO
Third-Party-Access (service providers)   PAM-Owner     IT Management   Procurement, Compliance, App Ow. CISO

Important for auditability: For each component it must be clear where the evidence is produced (e.g. tickets, policy repositories, IdP logs, PAM reports) and who can reproducibly provide it on demand.

Governance that works in operation: policies, exceptions and change control

Zero Trust lives from policies. A policy is not just a document but a machine-readable rule (e.g. a Conditional Access rule) plus accompanying governance: versioning, approval, rollout, monitoring, exceptions.

Policy layers you should separate cleanly

• Principles: few, stable guidelines (e.g. “Admin access only via PAM”).
• Standards: concrete and verifiable (e.g. “MFA for all remote access”, “devices must be encrypted”).
• Technical enforcement: rules in systems (IdP, endpoint, network, cloud).
• Exceptions: time-limited, risk-based, with an owner and compensating measures (e.g. tighter segmentation, additional monitoring).

Template: minimum content for an exception process (audit-proof)

Exceptions are normal, but they must be controlled. A practical standard is a ticket or workflow template with the following mandatory fields:

• Resource/application, affected user groups or accounts
• specific policy being deviated from
• justification (technical/organizational), business impact without the exception
• risk assessment (e.g. low/medium/high) and data classification
• compensating measures (logging, segmentation, temporary privileges, monitoring)
• start date, end date (sunset), review date

Change-Control: Why Zero Trust is not a „set once“ task

New applications, new integrations, M&A, cloud migrations, changed workplace models: all of these alter access paths. Therefore Zero Trust must be integrated into existing change processes. Practically, this means:

• Every change with identity or network impact receives a security-impact check (short questionnaire).
• Policies are versioned; rollouts proceed in waves (pilot, controlled groups, broad).
• Rollback is planned: if a policy blocks too much, it must be clear how quickly and in a controlled manner it can be reverted without creating security gaps.

Implementation logic: Prioritize by risk, not by system landscape

Many programs fail because they are organized by technology buckets („first network, then IAM“). A risk-based sequence along typical attack paths and organizational bottlenecks is better.

Stage 1: Stabilize identity and privileged access

When attackers take over identities, „inside/outside“ is irrelevant. Therefore first:

• MFA for all users, especially for admin and remote access; strictly limit and use Break-Glass accounts in a controlled manner.
• PAM for administrators and critical systems (vaulting, time-limited admin rights, session traceability).
• Inventory and rotate service accounts; where possible migrate to more modern mechanisms (e.g., short-lived tokens).

Stage 2: Device compliance as an access condition

Conditional Access is only as good as the quality of device attributes. Define minimum requirements (encryption, patch level, EDR, screen lock) and tie these to access to critical resources.

Stage 3: Unify access paths (ZTNA/Proxy, segmentation)

Instead of broad network access (classic VPN), access-specific paths are established: users reach only the applications they need. Segmentation here does not necessarily mean microsegmentation down to host level, but first: separate critical zones, restrict east-west traffic, separate admin paths.

Stage 4: Sharpen the data and application view

By this stage Application Owners must deliver: data classification, critical transactions, interfaces, technical accounts. Zero Trust also concerns APIs (Application Programming Interface, i.e., defined interfaces between systems): who may retrieve which data at what frequency, and how is misuse detected?

Metrics: What you should measure to make Zero Trust controllable

Without metrics, Zero Trust becomes a matter of faith. With the wrong metrics you get activism. Good KPIs have three properties: they are (1) derivable from systems, (2) usable for decisions, (3) robust against metric manipulation.

KPI-Set 1: Identity & Access (IAM)

• MFA coverage: proportion of active user accounts with MFA, broken down by internal/external users and by privileged accounts.
• Strong authentication on risk: proportion of risky logins where additional factors were enforced (from IdP risk signals).
• Joiner/Mover/Leaver times: time to revoke an account after departure or role change; important for audit and insider risk.
• Orphaned accounts: number of accounts without a login for X days or without an owner assignment.

KPI-Set 2: Privileged Access (PAM)

• PAM coverage of critical admin accesses: Proportion of admin workflows that run through PAM (not just “PAM is installed”).
• Just-in-Time/Just-Enough-Access: Proportion of temporarily granted admin rights vs. permanently assigned privileges.
• Break-Glass usage: Frequency and quality of justification; every event is a review trigger.
• Credential rotation: Proportion of privileged credentials that were rotated within defined timeframes.

KPI-Set 3: Device Trust (Endpoint/Workplace)

• Compliance rate: Proportion of managed devices that meet minimum standards (encryption, patching, EDR).
• Shadow devices: Detected but unmanaged devices attempting access.
• Time-to-patch (critical): Time from availability to installation of security-critical updates (grouped by criticality).

KPI-Set 4: Network and application controls

• Reduced access paths: Number/proportion of applications reachable without broad network access (ZTNA/Proxy instead of “open network”).
• Segmentation violations: Detected unauthorized east-west connections (from network telemetry).
• Service account risk: Number of service accounts with broad privileges or without rotation/owner.

KPI-Set 5: Detection, Response and audit evidence

• Log completeness: Proportion of critical systems whose auth, admin and access logs arrive centrally (SIEM/log platform).
• MTTD/MTTR (trend): Mean Time To Detect/Respond as a trend, not an absolute truth; consistency of the measurement method is what matters.
• Policy drift: Deviations between the defined standard and the actual configuration (e.g. disabled rules, unreviewed exceptions).
• Evidence lead time: Time to produce the required evidence for an audit (tickets, reports, log excerpts). This is an underrated management indicator.

Reporting rhythm: Minimal but mandatory

A sensible cadence is monthly at the operational level (Security/IT operations) and quarterly in steering (sponsor, CISO, compliance). Crucial is that each KPI cluster answers a clear question, for example: “How likely is an account takeover?” or “How many exceptions are technically justified and time-limited?”

Audit and regulatory perspective: evidence instead of statements of intent

Whether ISO 27001, internal audit, or requirements from NIS2: assessments rarely focus on “do you have Zero Trust?” but on controls and effectiveness. Typical audit questions are: How do you ensure that only authorized personnel have access to critical systems? How are privileged actions logged? How are exceptions approved and monitored?

An audit-ready Zero Trust program produces evidence artifacts “by design”:

• Policy versions with an approval record (who, when, why)
• System reports: MFA coverage, PAM usage, device compliance
• Ticket evidence: exceptions with expiry date, reviews, risk acceptance
• Logs: admin and auth logs, central retention and access protection for logs (so that the logs themselves cannot be tampered with)

Practical note: auditors are more likely to accept exceptions when (1) the exception is time-limited, (2) a compensating measure is documented, and (3) the organization can show it is actively reducing exceptions (metric: “overdue exceptions”).

Costs, effort and operational impact: Where Zero Trust consumes real resources

Zero Trust has costs, but many do not show up as licenses; they occur as operational and project effort. Organizations that don’t plan for this create frustration and shadow IT. The main cost drivers:

• Identity data quality: authorization models, role maintenance, ownership (who is responsible for an account?).
• Application rework: legacy applications without modern authentication or with hard-coded accounts require modifications or upstream gateways.
• Service desk and communication: MFA resets, device enrollment, exception processes. Good self-service flows significantly reduce this burden later.
• Monitoring and incident response: more signals mean more triage. Without use-case prioritization, the SOC (Security Operations Center) becomes overloaded.

At the same time, operational benefits arise when implemented cleanly: fewer long-term admin rights, clearer access paths, faster deprovisioning, better traceability in incidents. These benefits should be made explicit as decision criteria, not assumed as a “side effect”.

Checklist: Ready to start in 30 days (without a big architecture debate)

The following items are chosen so they predominantly address governance and fundamentals and deliver quick impact:

• Appoint an executive sponsor; establish a Steering meeting cadence for 6 months
• Formalize Zero-Trust program management and owners for IAM, PAM, endpoint, network/SIEM
• Define the top-10 critical systems and data domains (can tie into existing protection-need or risk lists)
• Adopt a minimal policy set: MFA, admin access via PAM, device compliance for critical access, exception process with sunset
• Establish an initial KPI baseline: MFA coverage, orphaned accounts, break-glass usage, device compliance
• Define audit-evidence location: where are policy versions, reports, exception tickets, log evidence?

Common pitfalls and how to avoid them

“We’ll first build the perfect target architecture”

A target picture is important, but Zero Trust is an iterative operational model. Start with well-defined minimal policies and measure effects. Architecture matures with insights from exceptions, incidents and operational data.

“MFA everywhere” as the sole strategy

MFA is necessary but not sufficient. Without PAM, device compliance and logging, the risk from token theft, misconfigurations and overprivileged accounts remains high.

Unclear responsibility for service accounts and interfaces

Service accounts are often “ownerless”. Define ownership and rotation, otherwise a permanent alternate access path remains. This is especially true for integrations between business software, databases and integration platforms.

Too many exceptions without sunset

An exception without an expiry date is a hidden policy override. Measure overdue exceptions and make them visible in the Steering.

Conclusion: Zero Trust is a governance problem with technical levers

A Zero Trust strategy rarely fails because “the technology can’t do it”, but because decisions are not properly anchored: who sets policies, who bears risks, who provides evidence? If you define roles (owners), a RACI and a lean set of metrics, Zero Trust becomes plannable: exceptions are controlled, operations are not overrun, and audit requirements can be served with reliable evidence.

Start with identity, privileged access and device compliance, establish a strict exception process with Sunset and build your KPI set so that it underpins decisions. Then „Zero Trust“ will move from buzzword to operational reality in your IT.