Murali is the Executive Director at an American multinational investment bank and financial services holding company.
getty
For sales organizations, it is critical to secure customer data and data about sales activities, not just from outside attacks but also from employees who don't have the right entitlements. In the financial sector, in particular, any inadvertent access to data can cause massive financial losses to customers and the institution itself.
It would be so simple if all the functionality was served by logging into a single application. Unfortunately, many companies use several applications to complete a single step in their business process. When data navigates through these applications, different personas create data points specific to the application domain depending on their access.
Each application protects what the personas share, but it doesn't protect how the data is handled afterward. For those using a CRM tool like Salesforce, it helps to look beyond the provided sharing and security model when multiple applications are involved. The CRM is usually only one piece of the puzzle.
For example, a banker may initiate a loan opportunity from a sales application. The pricing is then sent to a credit application for underwriters to review. When the opportunity closes, it is sent to an implementation system where a service specialist dispatches the loan.
As you can see, the data takes multiple hops. In addition to preserving the integrity of data, there needs to be consistent data visibility across applications. The objective is to secure data consistently for each step to establish mutual trust among user groups and applications. Here is a general overview of the process:
1. Standardize personas across applications based on their job functions (banker, sales associate, etc.) and assign each user to a persona.
2. Identify different types of data you want to protect—such as sales transactions—and establish a minimal level of access. Also, identify whether related data should have its own entitlements or rely on its parent.
3. Map the features each persona is entitled to by default, such as the ability to view sensitive information to approve a loan. If there is a need to hide or protect certain attributes of the data, consider exposing them only using an interface where certain personas can interact to view or make updates.
Based on this process, let's look at some key factors to keep in mind.
1. Personas And Roles
Many companies conflate personas and roles, but they are different:
1. Personas are given access to specific types of data and the features built using them.
2. Roles give access to individual records and actions applicable on them.
Within each persona, you'll need to define data-specific roles (for example, "loan owner" or "team member") and then map the actions each role can perform across applications.
Some roles could enable actions to create related data within the application domain, and this data may inherit access from the parent data or have its own set of role-action mappings. Role assignments should be flexible so that users can be assigned different roles on different records. Sometimes, users may get access to a single record in different ways, so there should be business logic to determine which role gets precedence.
Features and actions can be shared between personas and applications. Everyone sees the same data but they should have a different set of features and actions.
2. Named Access
Next, assign users with roles for underlying data. This is the simplest and most manageable data entitlement because it shows a clear understanding of data ownership at the lowest levels.
3. Implicit Access
Your business may have users performing specialized job functions and assigned roles based on rules defined by the business. Analysts, for example, could be auto-assigned as team members on customer accounts or related transaction data based on customer region or segment.
These users can be added to a group and managed without explicitly assigning or removing them from the underlying data. It is necessary to keep these rules to a handful so that the process is manageable in the long run.
4. Cross-Functional Feature Access
It is typical for users to perform multiple job functions. Since users are aligned with one persona, there should be a provision for users to get access to features that aren't normally available as part of their primary job function.
This can be a temporary or permanent delegation. Create a simple mapping between users and those cross-functional features with end dates, if any, and establish a process to send it to designated feature owners for approvals.
5. Manager And Hierarchy Access
Data that team members are given access to can be visible to your managers and their managers, but this can become tricky depending on how your company opens up entitlements at different levels.
Some businesses want to lock visibility to only those named on the record due to regulatory requirements. For example, a lead about mergers and acquisitions should be kept private from everyone.
Business needs to define whether to have open or closed entitlements for each type of data for reporting hierarchies. To be manageable, the data access for these hierarchies should only go up a few levels. It also doesn't need to completely mimic the HR worker hierarchy.
Conclusion
Most businesses have this information scattered across applications. Coverage derivations for manager and hierarchy access may also be calculated inconsistently. Or, features may be duplicated and named differently, causing the applications to interpret the data differently for the same user.
Because of these challenges, consistent visibility across all applications can enable trust in the user community and increase adoption. To do this, companies should centralize the entitlement data for reference while keeping the core data within the application domain. This process can also help application owners comply with audit requirements and compliance reporting by having one source of truth.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
