Zero Trust is a name for an idea, not a product. The idea is simple to state: no request to use a system or see data is trusted just because of where it comes from. Being inside the office, or on the company network, does not on its own settle anything. Each request is checked on its own terms, every time.
This article explains the idea in plain language. It is not security advice and it does not describe how to configure any system. One thing to be clear about before you start. Nothing here tells you whether any document satisfies anything, and nothing here identifies what you are obliged to produce. Which frameworks, standards and obligations apply to an organization varies by organization, by industry and by jurisdiction, and working out which ones apply to you belongs with a qualified professional who knows your situation.
The questions behind the idea
Most descriptions of Zero Trust come down to a few questions asked about every access request:
- Who is asking? The person or service making the request, identified individually rather than through a shared account.
- What are they using? The device the request comes from, and whether it is one the organization knows about.
- What are they asking for? The specific system or data, rather than broad access to everything nearby.
- Should they have it? Whether that person, in that role, has been approved for that access.
The approach also leans on giving each person only the access their role needs, and on reviewing that access when roles change.
Where documentation comes in
Whatever approach your organization takes, the answers to those questions live in records. Those records are what this site is about.
| Question | Record that answers it |
|---|---|
| Who is asking? | A list of individual accounts and their owners |
| What are they using? | A device inventory with an owner for each device |
| What are they asking for? | A list of systems and the data each one holds |
| Should they have it? | Access approvals and the dates of access reviews |
If those records are current, anyone can see who has access to what and why. If they are out of date, the questions have no reliable answer, however the systems are set up.
How to start
- List your systems. Name each system and the kind of data it holds.
- List who has access. For each system, record the individual accounts that can use it and who approved each one.
- Write down the decisions. Record which approach your organization has chosen, who chose it and on what advice. How it is put in place belongs with a qualified professional who knows your environment.
- Review on a cadence. Choose a review cycle, write it down, and record each review with its date and outcome.
What it is not
Adopting the idea is not a certificate or a finish line, and the records do not show that any system is safe. They show who has access to what, on whose approval, as of a date.
When you are ready to gather the documents that sit alongside this one, work through the Trust Center Document Checklist page on this site and fill the gaps one document at a time.