What Is Zero Trust and How Do You Implement It at a 30-Person Company?

Zero trust is a security model that grants access based on who is asking and what device they are asking from, verified on every request, instead of trusting anything because it sits on the right network. For a 30-person company the practical version is reachable with tools most SMBs already pay for: single sign-on, multi-factor authentication, managed devices, and access granted by role. Configured that way, your team signs in once, gets exactly the tools their role needs, and passes customer security reviews with settings you can point to. This post explains the model in plain terms and lays out what implementing it actually involves at SMB scale. The math is anchored at 30 people, and the structure holds the same way at 5 and at 150.

The Model in Plain Terms

Traditional network security draws a perimeter. Inside the office network or the VPN, you are trusted; outside, you are not. That model assumes the perimeter is where the risk stops, which stopped matching reality once companies ran on SaaS apps, laptops at home, and phones on hotel Wi-Fi.

Zero trust, defined formally in NIST Special Publication 800-207, replaces location with verification. The tenets that matter for a smaller company condense to a short list:

• Every app, service, and data store is a resource that deserves its own access decision, no matter where it runs
• Access is granted per session, based on identity, device health, and policy, and is re-checked rather than remembered
• No user or device is trusted by default because of the network it sits on
• Access follows least privilege: each person gets what their role needs and no more
• Sign-in activity and access grants are logged, so you can see who reached what and when

Nothing in that list names a firewall appliance or an enterprise budget. It describes decisions about identity and access, which is why the model scales down so well.

Why It Fits a 30-Person Company

Zero trust has an enterprise reputation because the early adopters were governments and large tech companies migrating away from sprawling internal networks. A 30-person SaaS-first company skips that migration entirely. There is no legacy data center or decade of network exceptions to unwind. The stack is already a set of cloud apps behind logins, which means the raw material of zero trust, identity-based access to discrete resources, is already how everything works. The remaining step is enforcing it deliberately instead of relying on defaults.

Being small is an advantage here in a second way: the roles are countable. Mapping who needs which tools is an afternoon of thinking at 30 people and a committee process at 3,000. Configuring access by role from day one means every future hire inherits the design, and if the company grew up on out-of-the-box settings and personal favors instead, the same mapping exercise fixes it now.

The Five Pillars, Sized for SMB

CISA's Zero Trust Maturity Model organizes the work into five pillars. At enterprise scale each pillar is a program; at SMB scale each maps to a tool category you likely already run:

• Identity. One identity provider in front of every app, with MFA enforced rather than merely available. Google Workspace, Microsoft Entra, and Okta all cover this tier of company.
• Devices. Company laptops enrolled in device management, so disk encryption, screen lock, and OS updates are enforced by policy instead of by each employee's habits.
• Networks. Treat every network as untrusted. With SaaS apps behind SSO, the office Wi-Fi grants no special access, which is the point.
• Applications and workloads. Every app sits behind the identity provider, access is assigned by role, and admin rights are separated from daily-use accounts.
• Data. Know where customer and company data lives, restrict it to the roles that need it, and turn on the audit logging your existing tools already include.

The pillars are also a useful honesty check. A company that has SSO but leaves MFA optional, or manages identity carefully while laptops go unmanaged, has a gap in a specific named place rather than a vague sense of being behind.

What Implementation Looks Like in Practice

The implementation order that works at this scale starts with identity and ends with review cadence:

• Put one identity provider in front of everything. Inventory your apps, connect them to SSO, and retire shared logins. Apps that cannot do SSO get a managed password vault as the fallback.
• Enforce MFA for every account. Enforcement policy, not a recommendation in the onboarding doc. Phishing-resistant methods like passkeys or hardware keys are the strongest option where your provider supports them.
• Define roles and assign access by role. Engineering, sales, finance, and operations each get a defined bundle of apps and permission levels. New hires get the bundle, and nothing arrives as a one-off favor.
• Enroll company devices in management. Encryption on, screen lock on, updates current, and the ability to lock or wipe a laptop that walks away.
• Wire offboarding to identity. Departure means one action in the identity provider that closes every downstream session, the single clearest payoff of the whole model.
• Review access on a cadence. A short quarterly pass over who has access to what, with special attention to admin rights, keeps the design true as the company changes.

Sequenced this way, each layer makes the next one easier, and the early layers deliver value on their own even before the later ones exist. An experienced partner compresses the timeline because the app-by-app SSO wiring, MDM policy baselines, and role definitions are work they have done many times across many stacks, while a team doing it for the first time learns each vendor's console as they go.

What You Gain From a Zero Trust Baseline

The finished state earns its keep in visible ways:

• Customer security questionnaires and vendor reviews become paperwork you answer from settings that already exist
• Onboarding delivers a fully provisioned first day, and offboarding is one verifiable action instead of a memory exercise
• A lost or stolen laptop is an inconvenience rather than an incident, because the device is encrypted and its sessions can be closed remotely
• Access records exist when an insurance renewal, an audit, or an enterprise deal asks for them
• The security model no longer depends on any single person remembering who was given what

Companies that put this baseline in early also find that compliance frameworks like SOC 2 stop looking like a mountain, because the controls auditors ask about are largely the ones above.

Do you want the zero trust baseline without spending your own weeks in admin consoles? ScaleIt implements SSO, MFA, device management, and role-based access for startups and SMBs as part of managed IT support. Book a free call and we will map the five pillars against your current stack.

Cross-referenced against NIST Special Publication 800-207 (Zero Trust Architecture) and the CISA Zero Trust Maturity Model version 2.0 on 2026-09-10. Sources: https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.800-207.pdf, https://www.cisa.gov/sites/default/files/2023-04/CISA_Zero_Trust_Maturity_Model_Version_2_508c.pdf.