By Quokka Advisory
Start a zero trust pilot with a service people depend on. Understand its users, connections and recovery paths before choosing the next control. You need that operating context to judge whether a change will improve the service or introduce another failure point.
At Quokka, we design platforms, networks and access controls together, then work through implementation with the people who run them. For a zero trust pilot, we trace an access decision through the systems that enforce it and test what happens at the resource.
NIST SP 800-207 describes an incremental approach to migration. The following planning method applies that principle to a bounded delivery exercise; it is a suggested approach, with acceptance criteria the organisation should adapt to its own risks.
Select the resource and name its owner
Choose a business service with a clear purpose, such as processing payroll, sharing project documents or giving an external engineer access to a support application. Record what would happen if someone disclosed its data, changed a transaction or interrupted its operation.
Name the business owner and the person responsible for operating the service. The business owner defines legitimate use and accepts residual risk. The operating team needs authority and time to maintain the controls after the pilot.
Include a representative group of users and workloads. A pilot that tests employees but overlooks a background integration may miss an access path that remains active outside working hours.
Map the paths that keep the service running
Record the applications, data stores, identity services and connections involved. Include support, monitoring, backup and recovery. Check whether a user can reach the resource through an older interface or a direct network route.
Consider a payroll application. Employees may use a web interface, an integration may transfer approved payments, and administrators may connect through a separate management path. Treat each route as part of the service until the team has established its purpose and controls.
This map helps the team choose enforcement points. It also identifies dependencies that could interrupt service if someone changes a rule without understanding the required flow.
Describe the access policy in business terms
For each subject, define the resource and permitted action. Separate routine use from administration and bulk export. Add the conditions that matter to the decision, such as authentication strength, device posture, approval and grant expiry.
Be explicit about missing information. A posture signal from yesterday may be too old for one resource and acceptable for another. Record the freshness limit and the response when the signal is unavailable.
Set session and revocation expectations. If a manager removes an entitlement, specify how soon the relevant access should end and how the team will demonstrate that it did.
Agree the tests before enforcement
Ask the team to prepare four sets of tests. Permitted-use tests demonstrate that people and workloads can complete approved activities. Denied-use tests cover unauthorised objects, actions and alternate paths. Change tests cover expired grants, changed posture and revoked access. Failure tests cover dependencies and recovery.
Define acceptable service impact with the owner. A rule that blocks a legitimate critical process needs investigation, even when it produces the expected security log.
Use a representative environment or a controlled pilot group, with an agreed rollback trigger. Observe the effect of a change before extending it to a wider population. Keep a record of unresolved defects and accepted exceptions.
Hand over a service the team can operate
Before expanding, have operations staff explain an access decision, investigate an unexpected denial and recover from a dependency outage. Give them the policy owner, support path and evidence location. If they cannot operate the design under those conditions, the delivery work still needs attention.
Report coverage using a defined denominator: tested in-scope resources divided by all resources in scope. Disclose untested routes. Track revocation time, expiry failures and support incidents caused by the new policy, alongside the access gaps the pilot closed.
Use that evidence to choose the next service or capability. Similar dependencies may make one extension straightforward; a fragile legacy system may need a separate design. The pilot should improve the next decision as well as the service it protects.
Download the Quokka Zero Trust Architecture Implementation Guide for a pilot worksheet, implementation tables and acceptance checks that help turn this planning method into delivery work.