You may already have useful building blocks for Zero Trust: individual accounts, access approvals, managed devices and security logs. The next step is to check how well those controls protect a particular service. You do not need to rename every policy or buy a new platform to begin.
The basic idea is simple: being inside the company network is not enough reason to grant access. Check who or what is requesting access, what they need and whether the request meets your rules. Access to one system should not automatically open the rest.
Start with a real task
Take a support employee who needs to investigate a customer problem. Ask which application they need, which customer records they can see and what happens when the task ends. Include any route that bypasses the normal login, such as a local administrator account or an API key.
The examples below are practical design options, not a required checklist. Choose controls that fit your service and the risks you need to manage.
1. Make existing login rules cover the actual access routes
You already have: central sign-in and multifactor authentication.
Improve it: check that the customer-support application actually uses those protections. Look for separate local logins and recovery routes. Where the risk warrants it, require a managed device that meets your security settings. Define how emergency access will work without becoming a permanent bypass.
Keep: the access rule, evidence of its coverage and dated tests of allowed and blocked access. Keep approved exceptions with an owner and a review date.
2. Narrow permissions instead of giving everyone administrator access
You already have: access requests approved by a manager.
Improve it: approve the particular role needed for the job. A support employee may need to view a record without changing billing settings or exporting every customer. Use time-limited elevated access where the system supports it and the task justifies it.
Keep: the approval, assigned role and record of removal or expiry. Check what happened to active sessions when elevated access ended.
3. Apply the same thinking to software accounts
You already have: an integration that moves data between applications.
Improve it: give the integration its own identity and only the permissions it needs. Name a person responsible for it. Avoid sharing a broad administrator credential across unrelated integrations.
Keep: the owner, permitted actions and credential-management records. Retain a test showing the integration can do its job but cannot perform an unrelated privileged action. Do not put secrets in the evidence folder.
4. Limit what a compromised account can reach
You already have: a VPN, firewall rules or separate production systems.
Improve it: check that access reaches only the required application or service. A successful VPN login should not be the sole permission check for every internal system. Test the intended restrictions rather than relying only on a network diagram.
Keep: the approved access paths and dated test results. Record unexpected routes and how they were corrected.
5. Connect logs to a decision
You already have: sign-in and administrator activity logs.
Improve it: decide which events need attention and who acts. For example, investigate a disabled account that still has a usable session. Document whether you terminated access, found an approved exception or needed further work.
Keep: the event, investigation and resulting action. A dashboard screenshot alone does not show that someone handled the problem.
Make one change safely, then expand
- Choose one workflow and identify its users, devices and service accounts.
- Write down what should be allowed and what should be denied.
- Pilot the rule with a small group. Test normal work and recovery before wider enforcement.
- Keep a rollback plan. Review blocked legitimate work as well as missed restrictions.
- Update the control description and assign someone to maintain it.
Do not remove existing safeguards just because a replacement is called Zero Trust. Legacy systems may need an interim restriction while you work toward a better design.
How this fits SOC 2
SOC 2 does not require every company to adopt a product or complete a universal Zero Trust checklist. The AICPA’s access-control guidance includes Zero Trust among possible techniques. Your controls still need to address the applicable criteria and your service commitments.
These examples can support access restrictions, least privilege and security monitoring. They do not cover the whole SOC 2 program. For a Type 2 examination, retain evidence across the examination period. A configuration checked today does not establish how it operated throughout that period.
Use your SOC 2 check-in to confirm that the improved controls are still working. Update access rules when jobs, systems or service needs change.
Sources
Principles and staged adoption: NIST SP 800-207, Zero Trust Architecture, sections 2.1 and 7. SOC context: AICPA Trust Services Criteria, especially CC6.1, CC6.3 and CC7.2. The examples above are practical illustrations, not an official crosswalk or an assurance conclusion.