A Zero Trust rollout plan for organizations with no CISO.

The shape of the problem

A typical small or mid-size organization arrives at Zero Trust through one of three doors. A cyber-insurance renewal questionnaire that suddenly asks about identity controls and segmentation. A new enterprise customer demanding a SOC 2 Type II within a quarter. Or a federal contract opportunity that pulls CMMC or FedRAMP language into the conversation. None of those doors gives the org a CISO. All of them give the org a deadline.

What follows in most cases is some combination of: a vendor pitch deck for a Zero Trust Network Access (ZTNA) product positioned as a one-click solution, a six-figure proposal from a Big-4 advisory firm to “assess your Zero Trust maturity,” and a fortyish-page Zero Trust strategy PDF the IT lead has been told to read. None of those is a rollout. Two of them are deliberate confusions of the product layer (ZTNA, an SSE-adjacent capability) with the architecture concept (Zero Trust, a posture). The advisory deck will produce a heat map; the heat map will not produce a control.

The good news: a real rollout is more tractable than the discourse suggests, and most of the heavy lifting is identity work that the org should have been doing anyway. The hard part is sequencing — what gets shipped first, what gets deferred without lying to your insurer or your auditor, and what gets bought versus built around what you already own.

What 90 days actually looks like

For a 25–250 person organization with no dedicated security leader, the realistic rollout shape is 90 days end-to-end. Not because the work fits cleanly in 90 days — some pieces continue indefinitely — but because that is the window in which an external partner or an internal champion can credibly say “we are now operating under a Zero Trust architecture,” produce the artifacts a third party will accept, and hand the operational pieces off to whoever owns IT day to day. Anything claiming a 30-day full rollout is either selling a product or shrinking the scope.

Weeks 1–2: discovery and inventory

You cannot apply policy to assets you have not enumerated. The first two weeks are about producing a defensible inventory of identities, devices, applications, data classes, and external-facing surfaces. Most no-CISO organizations skip this step because it is unglamorous; most projects that go sideways do so because someone made a control decision against an assumed inventory rather than the real one.

Concretely: pull the user roster from your identity provider, the device roster from your MDM or endpoint manager, the SaaS roster from your SSO (and from your finance team’s subscription list, which will not match), and a list of every business-critical workflow with the systems it touches. Tag each by data sensitivity and by whether it is currently behind SSO. The output is a single sheet you will revisit weekly.

Weeks 3–4: the identity baseline

Zero Trust without a clean identity baseline is theater. The identity work is the universal first move: it is what makes every later control possible, and it is the layer that the audit, the insurer, and the attacker all care about most.

By the end of week four you want: every employee on the same identity provider, conditional access enforced for sensitive applications, phishing-resistant MFA (passkeys or FIDO2 hardware keys) for administrators, legacy authentication (IMAP/POP/SMTP basic auth, NTLMv1) disabled in production tenants, and a documented joiner-mover-leaver process tied to the IdP. If your IdP is Microsoft Entra ID or Okta you have all the primitives you need; if you are still leaning on Google Workspace for identity but have non-Google SaaS scattered across the org, this is the week you face up to that.

Weeks 5–8: conditional access and device posture

With the identity baseline in place, the next two-week block applies access policy on top of it. The framing that works for non-CISO buyers: every authentication attempt is evaluated against the identity, the device, and the resource — not just the password. The implementation is mostly configuration: conditional access rules that require managed devices for high-sensitivity apps, network-location rules that prompt step-up auth from unfamiliar geos, and risk-based policies that block sessions from impossible-travel patterns.

Device posture is the often-skipped half. You need to know which devices are managed, which are personal-but-trusted, and which are unknown — and you need policies that treat them differently. The MDM (Intune, Jamf, Kandji) is the source of truth here; conditional access subscribes to it. Most organizations have one of these tools already; few have the conditional access policies wired up to it.

Weeks 9–12: data, network, and continuous monitoring

The last block does three things in parallel. First, data: classify the handful of data stores that actually matter (the customer database, the financials, the source code repo, the engineering secrets vault) and apply access policies that match the classification. DLP can wait for v2; explicit access policy cannot. Second, network: segment the network paths that matter (production from corporate, finance from general, prod databases from prod app tier) using whatever you already have — cloud security groups, identity-aware proxies, or ZTNA if you bought one. Third, telemetry: turn on identity sign-in logs, conditional access logs, and the cloud audit logs for your top three SaaS providers, and route them somewhere queryable.

By the end of week twelve you should be able to answer, on paper and in a query: who has access to what, from which devices, under which conditions, with which sign-in trail. That is the substance behind “Zero Trust.”

The seven control moves to ship first

Compressed: if you have 30 days, not 90, ship these seven. In every engagement we run, these are the controls that compound — each one makes the next one easier and each one is independently defensible to an insurer or auditor.

1. Single identity provider for every employee. No more “the marketing team logs into Mailchimp with a shared password.” If it is a business application, it goes behind SSO.
2. Phishing-resistant MFA for every administrator. Passkeys or FIDO2 hardware keys, not SMS, not TOTP. Admin sessions are the bypass vector.
3. Conditional access for sensitive applications. The financial system, the customer database, the engineering secrets vault — each requires a managed device and recent authentication.
4. Legacy authentication blocked. IMAP/POP/SMTP basic auth disabled in production. NTLMv1 and unconstrained Kerberos delegation disabled in any AD environment. Modern auth only.
5. Privileged-access scoping. Break-glass accounts identified, password-vaulted, alerted on use. Day-to-day admin done from separate accounts with elevation. No global admin in the daily-driver mail account.
6. MDM coverage on every business device. Intune or Jamf or Kandji on the laptop and phone of every employee with access to sensitive data. Personal devices either enrolled or kept off the resource list.
7. Identity sign-in logs centralized. Even if all you have is a free Sentinel workspace or a Cloudflare Logpush to R2, get the sign-in events out of the IdP UI and into something you can query. You will need this the first time someone reports a phishing click.

Seven moves. Ninety days for the rest. Everything else — SOC, EDR, SIEM, ZTNA — layers on top of these; none of them work if these seven are missing.

Four mistakes that quietly add months

The patterns below are the ones we see in every no-CISO engagement that has been running a few months before we are called in. None of them are catastrophic on day one. All of them cost six months by month nine.

1. Tooling-first thinking

The vendor you talked to has a product that “does Zero Trust.” They are not lying; they are also not telling the full story. ZTNA, SSE, CASB, ITDR, XDR — each of those product categories solves a sliver of the architecture. Buying one before you have done the identity baseline is buying a steering wheel before you have a car. The right order: architecture decision first, control decision second, tool selection third, vendor contract last. Most rollouts that stall are tooling-first rollouts that found themselves owning three overlapping products and no policy.

2. Boil-the-ocean policy doc

Someone — often a well-meaning advisory firm — produces a 60-page Zero Trust Strategy document. It maps to NIST SP 800-207 and the CISA Zero Trust Maturity Model. It is mostly correct. It also has no shipping date attached to any artifact, no owner on any control, and no way to tell if you are doing the work. Strategy without a control list is theater. The 60-page doc becomes a quarterly read-aloud and the actual posture does not move. Replace it with a two-page control list, dated, owned, and reviewed monthly.

3. Skipping the inventory

The fastest way to ship a control that does not work is to ship it against an inventory you assumed. Almost every no-CISO org we have walked into has at least one of: a shared service account with broad access that nobody can explain, a SaaS subscription on a personal card outside SSO, a legacy domain controller that everyone forgot, a contractor account that has not been deprovisioned. Each of those is the bypass route for the policy you just shipped. The inventory work in weeks 1–2 is not optional; cutting it costs the rollout.

4. Network-only thinking

“Zero Trust” in some vendor materials still translates to “ZTNA replaces your VPN.” That is one application of the concept, not the concept. The architecture is identity-first; the network controls are a downstream consequence. Buying a ZTNA product without doing the identity baseline produces an expensive VPN replacement that still does not know who is on the other end of the tunnel. Identity first, then policy, then network. Reverse that order and the rollout pays double.

How to know it worked

Measurable outcomes by month four, on paper and in queries. Three categories.

Identity-surface metrics. Percentage of employees authenticating exclusively through the IdP. Percentage of sensitive applications behind conditional access. Number of legacy-auth attempts per week (should trend toward zero). Mean time from termination to access revocation (should land under 24 hours, ideally under one). Number of unmanaged devices touching sensitive applications (zero is the target; the realistic floor depends on your BYOD posture).

Detection-surface metrics. Coverage of sign-in events in your log destination. Mean time to detect impossible-travel or anomalous-location sign-ins (under 15 minutes is realistic with the right rules). Number of conditional access policies blocking versus the count of those merely reporting (block-mode is the goal; report-mode is a staging state). Frequency with which the alert path produces actionable signal versus noise.

Audit-surface metrics. The questions your insurer or your enterprise customer asks, answered with documented controls instead of narrative. The SOC 2 Type II gap assessment passing the access-management section without remediation. The CMMC self-assessment for Level 2 closing the AC and IA control families. The ability to produce, in a query, the answer to “who accessed this database in the last 30 days, from which devices.”

If a third party — auditor, insurer, regulator, customer security team — asks how you know your Zero Trust posture is real, the three lists above are how. Anything more is bonus. Anything less is theater.

When to hire, when to outsource

The candid version. You hire when you have enough sustained security work that one person, full-time, can drive a rollout and run the operational layer afterwards — usually around 200 employees, sometimes earlier in regulated industries. You outsource the rollout when the work is intense, finite, and benefits from a senior practitioner who has done it ten times. You hire and outsource together when you have the operational layer covered internally but need an architect on the design and the hardest decisions.

The wrong answer, which we see often: hire a mid-level security engineer and ask them to drive the rollout alone. The mid-level engineer does the work they know how to do (often EDR deployment, often vulnerability management), and the architecture work waits. The rollout slips two quarters. The engineer leaves because they were set up to fail. The organization is in the same place, with a lighter wallet and a SOC 2 deadline that is now closer.

If you are under 100 people and there is no full-time security work after the rollout finishes, an external senior partner running the project and a fractional CISO on retainer after is almost always the right shape. If you are 200+ and growing, plan to hire mid-rollout — the architect designs the role, the architecture, and the controls, and the new hire walks into a built environment rather than a green field.

Where to go next

For more on how we run security engagements end-to-end — including the Zero Trust rollouts the work above describes — see the Security & IT practice page. The seven-control list above is the spine of most of our Program engagements. If the question is “does this fit my org,” the answer almost always comes out of a short scoping call: send a note via confidential intake or call (510) 585-8844.

If you want the audit-by-audit detail of how the seven controls map to NIST CSF 2.0, NIST 800-53, CIS Controls v8, SOC 2, ISO 27001, and CMMC — the “how we use each framework” breakdown is on the practice page; deeper crosswalks go into the cornerstone we’re publishing next.

This is a cornerstone article from the Llab Technologies Insights series. We write at this depth on the questions buyers ask us before they hire us. Other planned cornerstones: AI security audits, executive identity hardening, and the build-vs-buy economics of custom POS systems.