What is “Compliant Access” or what makes access “compliant”? Compliant access relates to minimizing the risk associated with granting access to business assets via standards and policies. Such access not only applies to people but also to systems, applications, programs, or other business-related resources. Compliant Access Delivery uses a business modeling approach and synthesizes multiple Identity and Access Management (IAM) technologies to automate and maintain each user with the appropriate access to IT systems while continuously minimizing risk.

With Compliant Access the difficulty is in the detail, and that is where traditional solutions miss the mark. The keys to Compliant Access are the words “appropriate” and “business policy”. The former in relation to the access to be granted, and the latter in relation to the tasks to be performed while such access is permitted. It is vital to understand that an IAM system cannot deliver Compliant Access itself in isolation. Because each organization has their own particular language, processes, and policies, any IAM system must bridge the divide between the technical “system” world and the business “process” world. The more efficient this bridge, the better it will be. In terms of efficiency, in the technical world, this means mapping process-to-process; in the business world, this means they talk the same language.

However, it’s also important to note that an IAM system is nothing more than a tool to support the business and its policies. Indeed, one of the fundamental issues that organizations have with such systems is when inflexible software tries to dictate the processes and way ‘you’ do business. The business must then force itself to comply or engage in costly and time-consuming customizations.1 Because this both contradicts the way you do business and conflicts with your inherent culture, longterm, this is doomed to fail. Within the business, existing operating processes, industry norms, and regulatory restrictions define what is job appropriate, what is a risk, and what is non-compliant—the software is there to fulfil and to make that easy. In such a model, current business policies and compliance regulations enable us to measure and determine Compliant Access. In every instance, the target to be met is a well-defined goal against which the organization’s current state can be clearly measured.

To achieve such goals, EmpowerID leverages an organization’s business model and language to both enforce and to provision Compliant Access across Cloud and on-premise systems.

How Does Compliant Access Leverage Your Business Model?

With their existing Identity and Access Management systems, defining business appropriate access is a challenge for IT organizations. Traditionally, these systems are designed to manage only the technical aspects of access control and, as such, lack a conceptual “bridge” to tie the technical entitlements to the business’s operating model. As such, this lack of communication inhibits both the business processes and the activities or “functions” performed by its participants within each process.

Business Processes and Functions

All businesses can be broken down into a series of business processes performed in the course of the production and delivery of their goods or services. Each business process is itself, a series of tasks that can be performed by either internal or external participants in order to complete that process. Drilling deeper, each individual task in each process can also be broken down into the functions that are executed in the process of completing that task.

An example of a function would be the act of creating a purchase order within a much larger purchasing business process. Naturally, because such terminology is commonplace, business users can readily recognize the function of creating a purchase order. Furthermore, managers and auditors could easily and quickly identify who within an organization should be entitled to create purchase orders and are, therefore, permitted to perform this function. Similarly, those who are not entitled to create purchase orders, cannot.

Later, when managers need to review employee access rights periodically, it would be simple to see whether the ability to create purchase orders has been assigned to someone for whom it was no longer job appropriate. Again, this is still at a business level and using common terminology, and contrasts starkly with the often unintelligible names and descriptions of technical entitlements that grant access to systems and applications within the software itself. One can see that functions are the missing link that connects traditional technical access management with the world of business-friendly terms and recognizable job appropriate access.

Clean Separation Between Business and IT

Figure 1 illustrates the clean separation between the business and the technology that supports it.

Here you can see three levels within our organization: The Business Specialists, Application Specialists, and the Application Itself.

At the top, we have the Business Specialists. These are the process specialists within your organization and who have worked with the business to determine, develop, implement, and test the processes that you currently use. Though it’s not essential to have a high level of process maturity, the more mature an organization’s processes are, the easier it is to map to the supporting applications. The processes are separate, unique (you only ever want 1 single way of performing processes), and are comprised of multiple functions. Though each function will, itself, be made up of multiple tasks or work instructions/procedures, you should only have one tested, proven, and efficient way of performing a function–such as ‘create a purchase order’—within your business.

The Business Specialist would then work with the Application Specialist to map these defined business processes and functions to the application itself. At the application level, you can see how a single function can be made up of single or multiple modules from the app.

Figure 1 - Clean Separation Between the Business Side and the Technical Side

Risk Policies

As outlined, Compliant Access must be “appropriate” and adhere to an organization’s “business policies”. These business policies are specific to an organization and tailored to match how the organization operates, their industry, the processes executed to deliver goods or services, and the regulatory requirements to which it must adhere. Business processes are non-technical in nature and are independent of the IT systems an organization uses.

For example, an organization’s Customer Acquisition Process and related risks do not vary based on whether they use SalesForce.com , Hubspot, or an Excel spreadsheet as their CRM. It makes no difference to the process itself. Moreover, the functions that a user performs in their job role as part of these higher- level processes are already known. As such, they can be mapped out in advance and linked to the required business policy or policies before the IT system itself has been chosen: again, your processes define how you do business and, unless you’re a start-up in the very earliest of days, you will already be doing this.

Also, as part of this process, an organization can and will define what high risk functions merit special attention. This could be an isolated function, or it could be when combined with other functions and involve other factors, such as certain job roles. Furthermore, it’s possible that these latter functions could be low risk on their own but, when combined with others, then require special considerations to prevent fraud or other misdeeds. One classic example is Separation of Duties (SoD), where having the ability to create a purchase order and to approve a purchase order is fine when done by separate users. However, when policy permits a single user to perform both tasks, it’s now an unnecessary risk.

It crucial that risk policies are defined at the function level because these are the actual business activities an organization must monitor and control. Technical entitlements do not directly relate to business concepts or entitlements, and neither do risk policies. Consequently, trying to implement policies in this manner will only lead to confusion for business users, create a lack of visibility into what the user can actually do, and ultimately prove ineffective.

Mapping the Business World to the Technical

One question that’s often asked is, “If functions are the proper level to define business-appropriate access and risk policies, how do we empower them to take effect and become useful enforced in the technical world of hundreds of on-premise and Cloud applications?” (The question’s not verbatim.) The answer is in using the functions as the bridge between the business and the IT systems they employ.

As shown in Figure 1, your organization’s Business Specialists map out the business processes in full, including which roles are involved in these processes and the actual functions they perform [in this process]. The Application Specialists then work with them to transform the required bundles of functions into task-based application roles in the specific systems that will be used to perform these tasks.

EmpowerID supports two methods of mapping these:

  • the less granular model of mapping application roles to the functions they deliver
  • for some systems the ability to go a level deeper and map the fine-grained application permissions to functions.

In the latter, fine-grained, model, EmpowerID can discover which functions are granted by application roles, even if they’re not specifically identified in a mapping. In either case, the end result is a system which can identify the following:

  • Which IT entitlements grant which functions
  • Which IT entitlements grant which functions
  • The manner that they were assigned that access.

Functions bring business-friendly clarity to your heterogeneous IT landscape

Figure 2 - Mapping Business Functions to IT Roles and Entitlements

Zero Trust and Compliant Access Delivery

Once your organization has defined and identified what is business-appropriate access and what constitutes risky access, we can now implement the technical controls to deliver, monitor, and enforce access and compliance with business policies. Unfortunately, organizational security is no longer a simple internal/external = trust/no trust equation and requires a new framework for Compliant Access Delivery. This framework is a new way of thinking about security and is called Zero Trust. (And technology vendors are rushing to embrace its principles.)

Zero Trust is based on the idea that identity is the new control plane, and is driven by 3 elements: never trust–access to systems must always be strongly authenticated; always verify–authorization is based on both the identity of the user and the context of the request; and always enforce least privilege–only absolute minimum access is ever given.

This last principle of least privilege is a key concept of both Compliant Access and Zero Trust. Least privilege directs an organization to grant only the minimal appropriate access. This permits us to use Compliant Access’ business process modelling approach to add business appropriate and business risk to the determination of least privilege. Furthermore, when functions are mapped to technical entitlements, this allows an organization to define job appropriate access as it applies to a specific business in their specific industry. Finally, the last component for Compliant Access is adherence to an organization’s policies concerning risk and, specifically, what is defined as being acceptable/allowed or unacceptable/prohibited. In conjunction with Compliant Access, least privilege adds business risk policies into the equation to determine if this least privilege ‘level’ would still produce unacceptable risks. Identifying such cases allows the organization to then make an informed decision whether to accept, and make an exception, or reject it.

How is Compliant Access Delivered?

The success of your Compliant Access system does not rely solely on the power and flexibility of the IAM system and its ability to design compliant business-appropriate access policies. Success relies on your ability to enforce your business policies across as many systems as possible. Again, the IAM system is a tool that supports your business. A major impediment to achieving success is what is known as the Last Mile problem. The Last Mile refers to the proportionally more challenging and expensive final delivery and enforcement of Compliant Access within applications and systems. Here at EmpowerID, we realize that to produce maximal business value, Compliant Access must be “delivered” to your systems and applications, and not serve merely as a reference system for recording and evaluating policies. To that end, EmpowerID supports all modes of Compliant Access Delivery.

Gateway Enforcement

The gateway enforcement model prevents end users from directly accessing applications or systems. Instead, they must connect through a gateway which authenticates, authorizes and monitors their access. For web-based applications and APIs this is known as Web Access Management (WAM), or the Reverse Proxy Approach. In this model, web applications and APIs are protected behind the EmpowerID Application Access Gateway. No direct connections are allowed, and the Access Gateway enforces the organization’s authentication and Compliant Access policies. This model is the most common for on-premise or legacy applications.

A gateway enforcement model is also the best approach for enforcing least privilege Compliant Access to servers. Malware and hack exploits rely on network connectivity to the servers they are targeting. Here, EmpowerID’s Privilege Session Manager acts as a web-based gateway to provide authorized users with terminal access to Windows or Linux servers but without exposing the servers to actual network access. In addition, and in all cases, strong adaptive identity verification is enforced and sessions can be optionally recorded for later compliance investigation or verification.

Claims-Based Enforcement

An additional approach for modern web-based applications is the Federated Identity or claims-based model. In this model, federated applications trust a central identity and authorization source, such as EmpowerID, to deliver the identity information and Compliant Access as claims during login. The application trusts this information and uses it to both verify the user’s identity and to enforce Compliant Access within the application itself.

A sophisticated example of this can be seen in the AWS authorization model. First, AWS supports receiving AWS IAM “Roles” as claims and, second, these roles are then mapped within AWS to Access policies. An organization can define the functions granted by these AWS roles and ensure that user access is job appropriate and adheres to risk policies.

Provisioning Engine Enforcement

The last option available for granting and enforcing Compliant Access relies on the EmpowerID provisioning engine to provision permissions or application roles to managed systems using connectors. A good example of this is SAP Advanced Business Application Programming (ABAP) systems which rely on complex roles and profiles to grant users access. Roles and profiles in SAP authorize users to execute transactions known as TCodes within the constraints defined by the assignment of organization fields and their values. A gateway or claims approach is not possible in this case. Instead, policies defining Compliant Access and business risk are modelled in EmpowerID, but the end resulting access must be manually granted and revoked by the EmpowerID provisioning engine. The provisioning enforcement model is the most common and available for a very large number of systems with out of the box connectors. This model works for any system supporting the SCIM standard and can be extended to others through the creation of a custom connector.


Compliant Access is a critical component and concern of every organization today. When selecting an IAM solution to deliver compliant access there are several considerations, including how to actually deliver and enforce such access. Prior to that, however, it’s imperative that your organization understands that any chosen IAM solution cannot deliver compliant access on its own. First, it’s only a tool to enforce your policies; and second, that though the business and IT side do indeed need to be connected to work, your own processes and policies are always the prime movers.