Zero Trust Architecture: Practical Assessment Worksheet
Zero trust is not a product purchase or a network slogan. NIST SP 800-207 describes it as an evolving set of cybersecurity paradigms that shifts focus from static network perimeters to users, assets, and resources. It assumes no implicit trust solely from network location or ownership. Authentication and authorization for subject and device occur before a session to an enterprise resource. Assessment must therefore test a decision at each resource boundary, not ask whether organization has MFA or a VPN.
This worksheet creates evidence for defined scope, not architecture certification. List named applications, administrative interfaces, APIs, data stores, workloads, and support services; record unmanaged resources as scope gaps.
Build resource inventory
List each resource with owner, business purpose, data sensitivity, administration path, network exposure, dependencies, and recovery mode. “Internal application” is not sufficient identity. Split a resource when its user population, administrative surface, data class, or access policy differs. A customer portal, its production database console, and its observability dashboard require separate decisions.
For every resource, identify subjects and device classes. Document action, protocol, relevant location, authentication strength, device and risk signals, and session rules. Location may inform a decision, never grant trust alone.
Example decision flow:
request /admin/export
| subject: finance-admin role, phishing-resistant MFA
| device: managed, encrypted, current security agent
| policy: approved change ticket and approved network path
| decision: allow 30-minute session, no file download
| evidence: identity event, posture result, policy version, trace IDTurn policy into a testable decision
A policy statement must say what happens when evidence is missing. “Require compliant devices” cannot be assessed until compliant, owner, signal source, freshness window, fallback, and deny behavior are defined. Prefer explicit logic: allow a production administrator only when role is current, MFA requirement is met, device posture is fresh, device is managed, and request targets approved administration service. Deny when any required signal is absent. Route only a documented break-glass role through separate time-bounded policy.
Test decision inputs independently. Remove device-management signal, use stale posture, downgrade user role, change target resource, invoke with workload identity from wrong audience, and continue after entitlement expiry. Expected result is a recorded deny or step-up. Evidence should include policy version and decision trace, not a screenshot alone.
Evidence must reconstruct access
Collect artifacts that answer who requested which resource, from which device or workload, under which policy, and what decision occurred. Useful evidence includes identity-provider events, conditional-access result, device-posture assertion, policy evaluation log, application authorization event, gateway log, and resource audit record. Correlate with stable request or trace ID. Redact personal and secret data in reports.
Absence matters. If resource logs identify a user but not policy version, decision cannot be reproduced after policy changes. If a gateway knows posture but application cannot identify entitlement, authorization boundary may be unclear. Mark these as findings with affected resource, risk statement, owner, remediation, and retest evidence.
Separate administrative paths
Administrative interfaces need separate resource records, stronger authentication, restricted roles, and short sessions. Separate control-plane access from application use and workload permissions from human administration.
Break-glass access stays narrow, time-bound, monitored, and reviewed. Evidence includes eligible identity, activation, approval or incident reference, session, and revocation.
Completed assessment sheet
| Resource and action | Required policy inputs | Evidence | Owner | Result | Exception or remediation |
|---|---|---|---|---|---|
| production admin console: configure | current admin role, strong MFA, managed device, short session | policy export, denied stale-device test, session log | system owner | Pass/Fail | add device claim; retest date |
| payroll API: read record | service identity, audience, workload policy | token claims, API audit, deny wrong audience | API owner | Pass/Fail | restrict service role |
| document store: download | user entitlement, approved device, download rule | access event, posture result, policy trace | data owner | Pass/Fail | define data action policy |
| emergency access: recover | eligible role, activation record, expiry | activation log, session log, review record | incident owner | Pass/Fail | remove standing privilege |
A completed entry names policy version, evidence location, test date, tester, owner, and result. Pass means expected decision occurred for specified request and context. Fail means rule is absent, bypassed, unobservable, or produced unexpected result. Exception requires business reason, compensating control, approver, expiration, and remediation owner. No permanent “temporary” exception.
Assess rollout in slices
Do not declare a whole enterprise converted because one application has conditional access. Start with a high-value resource, map dependencies, write policy, run allow and deny tests, collect evidence, then measure operational failure modes. Check help-desk recovery, device replacement, contractor onboarding, service-account rotation, and incident response. A technically strict policy that has no recovery path may drive users toward unsafe workarounds.
NIST’s model centers resources rather than network segments. Network segmentation can remain useful, but it does not replace per-resource policy. MFA, endpoint management, identity federation, proxy, and logging can contribute, yet none alone equals zero trust. Decision quality comes from stated requirements, enforceable policy, observable evidence, and review when context changes.
Buyer questions
Ask for resource inventory, policy matrix, identity and device signal definitions, access decision traces, denied-test records, exception register, and remediation tracker. Ask how workload identities differ from human identities and how administrative resources differ from ordinary application use. Ask what happens when posture service, identity provider, or telemetry is unavailable.
Finish with an assessment record: scope, resource list, policy versions, evidence, tests, pass/fail outcomes, exceptions, remediation owners, and retest triggers. Reassess when a resource, identity source, device-management rule, or authorization path changes.
Preserve decision inputs
For each allow or deny test, retain policy object version, identity claim set with sensitive values redacted, device-posture timestamp, target resource identifier, evaluator result, and resource audit event. Record evaluator outage behavior separately: deny, reduced access, or approved break-glass. A reproducible access decision lets reviewer distinguish policy failure from missing telemetry and prevents location-based fallback from becoming unrecorded trust.