Practice — design a Zero Trust architecture for a remote workforce — Governance, Compliance & Career Readiness

This hands-on exercise brings Module 3 together. You will design a Zero Trust architecture for a mid-sized company whose employees work entirely remotely and access cloud-hosted applications and internal tools without any dedicated office network to anchor traditional perimeter defenses, forcing every access decision to rely on identity and device signals alone rather than network location.

Analogy🏏Cricket

💼 Think of it like business: GRC frameworks are the shared accounting standards of security. A company that reports earnings under a recognized standard lets investors, lenders, and regulators all read the same numbers the same way, instead of trusting a founder's hand-drawn chart. Adopting ISO 27001, SOC 2, or NIST CSF does the same for security posture, giving auditors, customers, and regulators one common language to judge maturity rather than each party inventing its own yardstick. This reveals that frameworks really sell trust: their product is a claim outsiders can verify without taking your word for it.

Step 1 — Specify Identity Verification

Specify how identity will be verified for each access request, including multi-factor authentication or passwordless passkeys as covered earlier in this module, and what device posture checks — such as up-to-date patching and disk encryption — must pass before a device is allowed to authenticate at all.

Analogy🏏Cricket

💪 Think of it like fitness: a serious gym checks two things before a heavy lift — that it is really you on the programme and that your body is prepared, screening posture and readiness so an unsafe attempt is stopped before the bar ever moves. Skipping that pre-check is how injuries happen. This design step applies the same gatekeeping to access: specify how each request proves identity, through multi-factor authentication or passwordless passkeys, and which device posture checks — up-to-date patching, disk encryption — must pass before a device is even allowed to authenticate. This reveals that verifying both the person and the condition of their equipment must come before any access is attempted.

Step 2 — Design Dynamic, Role-Based Access Policy

Design how access policy will be applied dynamically based on user role, device health, and resource sensitivity, and how micro-segmentation will contain any single compromised session from reaching unrelated systems across the company. A finance team member's laptop should never be able to reach the engineering team's production database regardless of which VPN or SaaS tool both happen to share.

Analogy🏏Cricket

🎬 Think of it like movies: a film set hands out role-specific passes, so an actor's lanyard opens the soundstage but not the accounts office, and the whole lot is compartmentalised so a breach on one set never spills onto another production. Access is scripted to the role, not to mere presence. Your policy design works the same way: access is applied dynamically from user role, device health, and resource sensitivity, and micro-segmentation contains any single compromised session from reaching unrelated systems. A finance laptop should never touch the engineering production database. This reveals that role-scoped, compartmentalised access stops one breach from becoming a studio-wide leak.

text

Sample dynamic access policy rules

Role        Resource            Required signal
Finance     Payroll system      MFA + managed device + office hours only
Engineering Production DB        MFA + managed device + posture check pass
Any role    Public marketing CMS MFA only (lower sensitivity resource)

Step 3 — Document the Design

Document your design using layered diagrams covering data flow, trust boundaries, and policy enforcement points, exactly as described in the documentation lesson earlier in this module. Keep the three views separate so a reviewer unfamiliar with the design can follow the identity flow, the trust boundaries, and the segmentation independently.

Analogy🏏Cricket

💰 Think of it like finance: a credible set of accounts separates the cash-flow statement, the balance sheet, and the income statement, so an auditor can trace liquidity, position, or performance each on its own clean page instead of untangling one blended ledger. That separation is what makes the whole thing reviewable. Document your Zero Trust design the same way, using layered diagrams for data flow, trust boundaries, and policy enforcement points, and keep the three views separate so a reviewer unfamiliar with the design can follow the identity flow, the boundaries, and the segmentation independently. This reveals that a design becomes auditable only when each concern is presented on its own statement.

Step 4 — Justify Against the NIST Tenets

Justify each major decision against the NIST 800-207 tenets covered earlier in this module: per-session least-privilege access, dynamic policy considering multiple signals, and uniform treatment of resources regardless of network location. This exercise mirrors the real deliverable a security architect would present to leadership before implementation begins.

Analogy🏏Cricket

📷 Think of it like photography: a professional doesn't defend a shot by saying it 'felt right' — every choice traces back to a stated intent for the image, and that justification is what separates craft from luck. Your final design step demands the same rigour: justify each major decision against the NIST 800-207 tenets — per-session least-privilege access, dynamic policy weighing multiple signals, and uniform treatment of resources regardless of network location. This mirrors the real deliverable a security architect presents to leadership before implementation begins. This reveals that a defensible design, like a strong photograph, explains every choice by intent rather than instinct.

A remote-first Zero Trust design must verify identity and device posture for every request, with no office network to fall back on.
Dynamic access policy should combine role, device health, and resource sensitivity rather than a single signal.
Micro-segmentation contains a compromised session, preventing lateral movement to unrelated systems.
Documentation should use separate layered diagrams for data flow, trust boundaries, and policy enforcement.
Every design decision should trace back to a specific NIST 800-207 tenet, not be justified by intuition alone.