When the business asks me for a remote access solution, my first question is usually straightforward: what do you actually need it for?
“We need remote access” does not yet tell me what we have to solve. I need to understand what the business wants to do, which activity it needs to support, and whether we are talking about a particular team or the whole company.
That may seem obvious, but this conversation determines many of the decisions that will shape the architecture. If we start with the product, we are choosing a solution before properly defining the problem.
First, understand what the business needs
Before discussing technology, I want to know which activity we need to enable.
Does a team need to work outside the office? Does a supplier need to maintain an application? Does internal audit need to consult information? Or are we preparing an alternative for when the usual access route is unavailable?
All these situations may require remote access. They do not necessarily need the same permissions, conditions or operating model.
There is another question worth asking early: why do we think everyone needs it?
Sometimes there is a genuine need across the organization. At other times, a broad scope is proposed for convenience, to anticipate future requests, or because we have not yet worked out who actually needs access.
I prefer to clarify this before implementation. Giving the whole company access and later discovering that only some people use it has consequences: permissions to maintain, reviews, support and, depending on the solution, licences.
Where SABSA fits
For me, SABSA helps maintain the link between what the business needs and what we design.
If the business asks for “robust” access, we need to turn that word into specific requirements. What availability does it need? What happens if the service fails? How long can the activity be interrupted? Is there an alternative?
If it wants to know who does what and where they can connect, we need to define the identities we will use, the permissions required for each activity and the information we need to record.
These questions directly influence the solution.
SABSA starts with business objectives and maintains their traceability through to the architecture. That is the part I want to apply: being able to explain why each requirement exists and which need it addresses.
Who, to what, for what purpose and for how long
Once I understand the problem, I need to make the access scope specific.
Who. Who actually needs it? Belonging to a department does not mean someone should have the same permissions as every colleague.
To what. Where do they need to connect? “The environment” is too broad. We need to identify applications, services or resources.
For what purpose. What do they need to do? Reading information, changing it and administering a platform are different activities.
For how long. Is this a regular need, a periodic activity or a task with an end date?
These four questions let us define access that makes sense. They also give us a basis for reviewing it later.
If we cannot explain why someone needs a permission, we do not yet have enough information to grant it with a clear rationale.
- Business need
- Requirements and scope · SABSA
- Access decisions · Zero Trust
- Implementation and operations
- Review usage, permissions and exceptions
Review feeds back into requirements and scope.
Applying Zero Trust to access
With the scope defined, I apply Zero Trust principles to minimize implicit trust.
Someone should not receive broad access simply because they work for the company or have already connected. We need to evaluate their identity, the requested resource and the conditions under which access takes place.
NIST SP 800-207 reflects this approach: access is evaluated per session, and authorization to one resource does not automatically grant access to others.
We then need to decide how to put this into practice: the authentication required, the conditions the device must meet, the permitted actions and the changes that require access to be reassessed.
We must also understand the limitations. Some applications support detailed roles; others distinguish between only a few permission levels.
If the technology cannot enforce the scope we need, we have to make that clear. The problem still exists even if the solution is marketed as Zero Trust.
What about exceptions?
Exceptions happen. A common case is someone from another department who needs to consult information without repeatedly asking the team responsible for it.
Internal audit, for example.
The need may be entirely justified. But there are still questions to answer: which information is needed? Could access be read-only? Are downloads required? For how long? Who validates the scope?
Those answers help us find the right way to enable access.
What I try to avoid is a need to read information turning into broad, permanent permissions because that was the quickest option.
For me, an exception needs a clear reason, an owner and a review. If the same exception is requested repeatedly, we should revisit the design. We may be dealing with a recurring use case that deserves its own access role.
My approach is to keep exceptions to a minimum. Those that exist must remain explainable and justified.
The solution also needs to be operated
The architecture must work when requests, changes and incidents arrive.
Who validates that someone needs access? Who enables it? Who reviews permissions? Who acts when the person changes role? And who responds when the service stops working?
We need to design that too.
To define an operating model and a RACI, I need to understand how the technology works. Even if I am not administering it every day, I have to understand its capabilities, dependencies and limitations.
Otherwise, we may assign responsibilities a team cannot fulfil or leave activities that everyone assumes somebody else handles.
The operating model should make those situations clear.
Then, check who actually uses it
After implementation, I want to compare our assumptions with what actually happens.
If we have enabled access for a particular population, how many people use it? How often? For which activities?
One useful indicator compares people with access enabled against those who actually used the service during a defined period:
Observed adoption = unique users who used the service / users with access enabled × 100
Before using it, we need to agree what counts as usage and how we count users joining or leaving. We should also distinguish between roles: someone working through that access daily has a different need from someone using it for a quarterly review.
The aim is to check whether the original scope was properly defined.
Sometimes everyone is assumed to need access, but the usage data tells a different story.
Low usage does not automatically mean access is unnecessary
We have to interpret the data.
Some users may not need access, but there may also be technical problems, missing guidance or an activity that has not started yet.
And some infrequent access remains necessary. A continuity solution may go unused for months under normal conditions. In that case, we need to check that it is still justified and works when tested.
I would not remove access solely because it has not been used during a period. I would review why it exists and how often we expected it to be used.
The KPI helps us ask better questions. The decision needs context.
Usage and security need separate measures
High usage does not demonstrate that permissions are well defined.
To check that, we need to review other aspects: whether each role has the access it needs, whether exceptions remain justified, whether activities can be attributed to an identity, and whether permissions are reviewed when the need changes.
Adoption tells us whether the service is being used. Access reviews help us check whether it is being used within the appropriate scope.
We need both to assess the result.
Keep the reasoning we started with
The business changes. New applications, activities and access needs appear.
That is why the architecture needs review throughout the life of the service. The relationship between need and permission must remain explainable.
This is how I understand the combination of SABSA and Zero Trust: start with what the business needs, define access with as little implicit trust as possible, and then check that the scope remains appropriate.
When a new request arrives, return to the same questions:
Who needs access, to what, for what purpose and for how long?
Further reading
Official sources for checking and exploring these concepts. This article presents a practical approach; it does not reproduce the references’ full requirements.
Examples are illustrative. Implementation decisions should be adapted to each organization’s requirements and dependencies.