MANAGING APPLICATION ACCESS RIGHTS OF PROJECT ROLES TO MAINTAIN SECURITY OF CLIENT IDENTIFYING DATA

FIELD OF THE INVENTION

[001] The invention relates to security of client identifying data and, in particular, to managing application access rights of project roles to maintain security of client identifying data (CID) and/or adherence to regulatory requirements related to client identifying data.

BACKGROUND OF THE INVENTION

[002] Traditionally, administrators manually configure individual applications for each user or user group (e.g., administrative users, non-administrative users, etc.) so that the user or user group has certain specified access rights via the individual applications. As such, in order to facilitate a user in his/her assigned role (e.g., job role, project role, etc.), applications and/or their access rights are typically requested and approved for the user on an individual basis. However, because an administrator assigning the access rights may not have knowledge regarding the full scope of the access rights nor knowledge regarding the full scope of the user's assigned role, access rights may be assigned to (or enabled for) users without regard important to business and legal risks. For example, an administrator may not be aware of whether and what type of client identifying data is accessible via requested access rights, the clients to which the client identifying data belongs, the interactions intended or otherwise planned for a user's role, etc. Thus, for instance, an administrator may inadvertently enable access rights (with access to client identifying data) for a user whose role is intended for interactions outside of a jurisdiction that prohibits the transmission of client identifying data outside the jurisdiction, thereby risking civil fines or criminal penalties associated with such prohibition, as well as negative effects on execution of industrialization and outsourcing/offshoring strategies. These and other drawbacks exist.

SUMMARY OF THE INVENTION

[003] The disclosure addressing these and other drawbacks relates to methods, apparatuses, and/or systems of maintaining security of client identifying data and/or adherence to regulatory requirements related to client identifying data. As an example, due to laws of various jurisdictions, organizations or other entities may face high civil penalties or even criminal charges if client identifying data handled by the organizations or other entities are transmitted outside the respective organization, outside a certain jurisdiction, etc. (e.g., intentional or unintentional release of CID by an employee or contractor).

[004] In an implementation, client identifying data may be protected by managing application access rights of project roles (or other roles). For example, applications and/or their access rights that are available to be assigned to (or enabled for) project roles may be pre-identified and pre-certified, and the information regarding the pre-identified/pre-certified applications and/or access rights may be stored in an application information repository. As such, during assignment of access rights to roles of a project, information regarding the access rights may be rapidly obtained from the application information repository and analyzed to determine whether the access rights should be assigned to (or enabled for) the roles. In one use case, for instance, attributes of both an access right and a role (for which the access right is requested) may be automatically analyzed to determine whether the access right should be assigned to (or enabled for) the role. The attributes may, for example, indicate whether the access right allows access to client identifying data, the client(s) or type(s) of client identifying data to which the access right allows access, the type of interaction for which the role is intended, whether the role is limited to a domain (or domains), or other values. In this way, among other benefits, one objective technical solution described herein facilitates rapid assignment (or enablement) of access rights to/for roles while reducing human-induced errors (e.g., relating to information regarding the access right) and maintaining security of client identifying data when assigning (or enabling) the access rights for the roles.

[005] In an implementation, a user interface may be programmed to facilitate the assignment (or enablement) of access rights to/for roles. For example, upon receiving user input indicating a role, the user interface may work with one or more subsystems (as described herein elsewhere) to obtain and present information indicating one or more applications and/or application access rights that are available to be assigned to (or enabled for) the role. As another example, upon receiving user input indicating applications to be used for the role, the user interface may work with one or more subsystems to obtain and present information indicating the access rights (of the applications) that are available to be assigned to (or enabled for) the role. Upon presentation of the access rights, for instance, a user may easily select from the presented access rights to initiate the assignment (or enablement) of selected access rights to/for the role. Thus, the system may provide an enhanced user interface that works in conjunction with computer subsystems to obtain (e.g., from a repository) and present appropriate application and/or access rights information, as well as initiate the assignment (or enablement) of the access rights for roles. Among other benefits, such a user interface provides efficiency in the assignment (or enablement) of access rights for roles without users having to individually configure applications for individual users or user groups. In addition, such a user interface programmed to work with the subsystems described herein further protects client identifying data when assigning (or enabling) the access rights for the roles.

[006] In an implementation, management of access rights for roles may be facilitated via automated remediation operations (as described herein elsewhere). As an example, when a user requests a particular application for a role, and the application has access rights that allows access to client identifying data, application information and role information may be obtained (e.g., from application information and role information repositories, from relevant users, etc.) to assess one or more of the following: whether the access right should be assigned to (or enabled for) the role, whether an alternative access right should instead be assigned to (or enabled for) the role in lieu of one of the access rights, whether the role should be limited before assigning (or enabling) one of the access rights or the alternative access right for the role, whether alternative roles should be created to supplement or replace the role, etc. Examples of information that may be obtained to facilitate such assessment may comprise information indicating applications or access rights that have already or previously been assigned to (or enabled for) the roles, users assigned to the roles, tasks assigned to the roles, processes assigned to the roles, objectives assigned to the roles, interactions (or interaction types) intended or otherwise planned for roles associated with a project, the client (or entity/entity type) that is identified by client identifying data to which the access rights allow access, etc.

[007] The obtained information may, for instance, be presented to one or more administrators, managers, or other relevant users to determine and/or approve further actions to be taken regarding the assignment (or enablement) of access rights to roles. For example, in an implementation, a determination may be made to limit a role to one or more domains, such as logical domains (e.g., user groups, organization divisions, organizations, etc.) or physical domains (e.g., jurisdictions, geographical areas, etc.) based on a determination that an access right of an application requested for the role allows access to client identifying data. A role may, for instance, be limited before an access right allowing access to client identifying data is assigned to (or enabled for) the role such that the role is not intended to (or otherwise planned for) interactions external to a particular organization, external to a certain jurisdiction, etc. In one use case, a role may be limited to one or more domains by removing a part of the role that is intended for interaction that is external to the domains. In another use case, a role may be limited to one or more domains by creating a new role that comprises a part of the original role that is not intended for interaction external to the domains and limiting the original role to the new role. In this way, interactions involving client identifying data may be limited to the domains (e.g., limited to interactions within an organization, limited to interactions within a jurisdiction, etc.). The limiting of such interactions to certain domains may, for instance, be necessary to ensure the adherence to regulatory restrictions related to exposure of client identifying data.

[008] As another example, in an implementation, an alternative access right may be assigned to (or enabled for) a role in lieu of an access right of an application requested for the role. In one implementation, the alternative access right may allow access to non-sensitive identifiers (or other information) that corresponds to client identifying data accessible via the requested access right. In this way, the number of roles that have access to client identifying data may be reduced, thereby increasing protection for client identifying data. In another implementation, the alternative access right may allow access to client identifying data associated with clients that have waived some protection for their client identifying data (e.g., the client may have signed a waiver to allow for offshore/outsourced data processing of their client identifying data). The assignment (or enablement) of alternative access rights, the limiting of roles, or other actions may be efficiently facilitated via the collection of pre-stored application information, role information, or other information.

[009] It should be noted that, while some implementations are described with respect to assigning (or enabling) application access rights to/for project roles, it is contemplated that, in some implementations, other access rights may be assigned (or enabled for) other types of roles.

[010] Various other aspects, features, and advantages of the invention will be apparent through the detailed description of the invention and the drawings attached hereto. It is also to be understood that both the foregoing general description and the following detailed description are exemplary and not restrictive of the scope of the invention. As used in the specification and in the claims, the singular form of "a", "an", and "the" include plural referents unless the context clearly dictates otherwise. In addition, as used in the specification and the claims, the term "or" means "and/or" unless the context clearly dictates otherwise. BRIEF DESCRIPTION OF THE DRAWINGS

[Oil] The invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawing and in which like reference numerals refer to similar elements.

[012] FIG. 1 is an exemplary illustration of a system for managing application access rights of project roles, according to an implementation of the invention.

[013] FIG. 2 is another exemplary illustration of a system for managing application access rights of project roles, according to an implementation of the invention.

[014] FIG. 3 is an exemplary illustration of assignments of application access rights to project roles, according to an implementation of the invention.

[015] FIG. 4 is another exemplary illustration of assignments of application access rights to project roles, according to an implementation of the invention.

[016] FIG. 5 is an exemplary illustration of a flowchart of a method for managing application access rights of project roles, according to an implementation of the invention.

[017] FIG. 6 is an exemplary illustration of a flowchart of a method for creating and/or modifying roles to maintain security of client identifying data and/or adherence to regulatory requirements related to client identifying data when enabling application access rights for roles, according to an implementation of the invention.

[018] FIG. 7 is an exemplary illustration of a flowchart of a method for managing user selection of application access rights for project roles, according to an implementation of the invention.

[019] FIG. 8 is an exemplary illustration of a flowchart of a method for maintaining security of client identifying data using alternative application access rights, according to an implementation of the invention.

DETAILED DESCRIPTION OF THE INVENTION

[020] In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the implementations of the invention. It will be appreciated, however, by one skilled in the art that the implementations of the invention may be practiced without these specific details or with an equivalent arrangement. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the implementations of the invention.

[021] FIG. 1 is an exemplary illustration of a system 100 for facilitating managing application access rights of project roles, according to an implementation of the invention. System 100 may comprise one or more computers and sub-systems that provide different protective measures to facilitate the security of client identifying data and/or adherence to regulatory restrictions related to client identifying data. The different protective measures may be used individually or in combination with other protective measures. The protective measures may comprise, for example, managing application access rights of project roles (or other roles), or other protective measures. Management of access rights of roles may comprise limiting roles to one or more domains (e.g., user groups, organization divisions, organizations, jurisdictions, geographical areas, etc.), adding or modifying roles to replace current roles, enabling certain access rights only for roles limited to one or more domains, adding or modifying access rights that are available for assignment to roles, or managing access rights using other techniques.

[022] As shown in FIG. 1, system 100 may comprise server 102 (or servers 102). Server 102 may comprise user interface subsystem 106, role subsystem 108, access subsystem 110, remediation subsystem 112, electronic storage 114, or other components. Server 102 may, for example, be part of a centralized or decentralized system.

[023] System 100 may also comprise user device 104 (or multiple user devices 104a-104n). User device 104 may comprise any type of mobile terminal, fixed terminal, or other device. By way of example, user device 104 may comprise a desktop computer, a notebook computer, a netbook computer, a tablet computer, a smartphone, a navigation device, an electronic book device, a gaming device, or other user device. Users may, for instance, utilize one or more user devices 104 to interact with server 102 or other components of system 100 (e.g., via network 120). It should be noted that while one or more operations are described herein as being performed by components of server 102, those operations may, in some implementations, be performed by components of user device 104.

[024] System 100 may further comprise role information repository 116 and application information repository 118. It should be noted that while role information repository 116 and application information repository 118 are shown in FIG. 1 as components separate from server 102, role information repository 116 and application information repository 118 may, in some implementations, be part of electronic storage 114.

[025] In an implementation, role information repository 116 may comprise role information indicating roles of a project (or other roles), applications or access rights requested for the roles, access rights assigned to (or enabled for) the roles, applications assigned to (or enabled for) the roles, users assigned to the roles, tasks assigned to the roles, processes assigned to the roles, objectives assigned to the roles, interactions (or the types of interactions) for which the roles are intended, or other information. A project may comprise one or more of a task, a process, or an objective. In an implementation, role information repository 116 may comprise one or more repositories where each of those repositories includes information related to roles of respective divisions of an entity, roles of respective entities, etc. As such, role information repository 116 may comprise a collection of repositories where each of the repositories includes role information.

[026] In an implementation, application information repository 118 may comprise application information indicating applications that are available to be assigned to (or enabled for) roles, access rights of the applications that are available to be assigned to (or enabled for) the roles, the data (or types of data) to which the access rights allow a role access when assigned to (or enabled for) the role, the client (or entity/entity type) that is identified by the data, or other information. In an implementation, application information repository 118 may comprise one or more repositories where each of those repositories includes information related to applications of respective divisions of an entity, applications of respective entities, etc. As such, application information repository 118 may comprise a collection of repositories where each of the repositories includes application information.

[027] In an implementation, the types of data may comprise client identifying data (e.g., direct CID, indirect CID (or sensitive identifiers), etc.), non-sensitive identifiers, or non-identifying data, other information. Examples of direct CID may comprise names, addresses, or other data identifying a client (e.g., "First- Name Last-Name," "Address- 1 Address-2," 230-123456.9h9, etc.). Examples of indirect CID (or sensitive identifiers) may comprise account numbers, credit card numbers, one or more artificial combinations of attributes that form identifiers (e.g., First-Name_Address-l_Last-Name_01), or other sensitive identifiers. Examples of non-sensitive identifiers may include one or more identifiers derived from a hashing of plain CID attributes or a mapping table (e.g., Xas987asdf98asdf9a), or other non-sensitive identifiers.

[028] In an implementation, the types of clients (or entities) may comprise ultrahigh net worth, global family office, high net worth, financial intermediates, core affluent, early affluent, corporate clients, asset managers, pension funds, banks, insurance companies, hedge funds, sovereigns, or other client (or entity) types.

[029] In an implementation, user interface subsystem 106 may be programmed to provide a user interface that facilitates assignment (or enablement) of access rights to roles while maintaining security of client identifying data. As an example, a user interface that is presented to a user may be programmed to enable a user to input role information, such as applications or access rights requested for the roles, users assigned to the roles, tasks assigned to the roles, processes assigned to the roles, objectives assigned to the roles, interactions (or the types of interactions) for which the roles are intended, or other information.

[030] In an implementation, upon receiving the role information via the user interface, user interface subsystem 106 may immediately initiate the processing of the role information by the appropriate subsystems (e.g., role subsystem 108, access subsystem 110, remediation subsystem 112, or other subsystems) so that the requested access rights or alternative access rights may be assigned to (or enabled for) the indicated roles or alternative roles (e.g., a limited version of the role, new roles created from the role, etc.). In another implementation, upon receiving the role information via the user interface, user interface subsystem 106 may store the role information in role information repository 116 so that the stored role information may later be processed by the appropriate subsystems to assigned (or enable) the requested access rights or alternative access rights to/for the indicated roles or alternative roles.

[031] In an implementation, role subsystem 108 may be programmed to obtain role information indicating one or more roles. The indicated roles may, for example, comprise roles associated with a project. A project may comprise one or more tasks, processes, objectives, or other project aspects. As an example, a role may be assigned to complete at least one task, manage at least one process, work toward at least one objective, or perform other project aspects.

[032] In an implementation, the role information may be obtained so that access rights (e.g., application access rights) may be assigned to (or enabled for) one or more roles to facilitate the tasks, processes, objectives, or other project aspects associated with the roles. As an example, role subsystem 108 may be programmed to obtain the role information from a user via a user interface (e.g., provided by user interface subsystem 106) through which the user may provide user inputs indicating roles for a project for which applications and/or access rights are to be assigned. As another example, role information (e.g., obtained from a user) may be stored in role information repository 116. The role information may, for instance, indicating roles of a project, applications or access rights requested for the roles, users assigned to the roles, tasks assigned to the roles, processes assigned to the roles, objectives assigned to the roles, interactions (or the types of interactions) for which the roles are intended, or other information. Role subsystem 108 may be programmed to obtain the role information from role information repository 116 when the role information is ready to be processed so that applications or access rights may be assigned to (or enabled for) the roles indicated by the role information. [033] In an implementation, role subsystem 108 may be programmed to obtain and analyze role information to determine one or more applications that are requested for certain roles (indicated by the role information), interactions (or the types of interactions) for which the roles are intended, etc. The requested applications may, for instance, comprise applications that are to be used by the roles (e.g., by users assigned to the roles). The interactions (or interaction types) may comprise interactions external to a domain (or domains), interactions internal to the domain, etc. Domains may comprise logical domains (e.g., user groups, organization divisions, organizations, etc.) or physical domains (e.g., jurisdictions, geographical areas, etc.). Determination by role subsystem 108 may be provided to appropriate subsystems (e.g., user interface subsystem 106, access subsystem 110, remediation subsystem 112, or other subsystems) so that the requested access rights or alternative access rights may be assigned to (or enabled for) the indicated roles or alternative roles.

[034] In an implementation, access subsystem 110 may be programmed to enable one or more access rights for roles associated with a project. As an example, access subsystem 110 may receive information indicating one or more applications that are requested for the roles (e.g., applications that are to be used by the roles) from role subsystem 108. Upon receipt, access subsystem 110 may determine access rights that are available via the requested applications.

[035] By way of example, with respect to a determined access right of an application requested for a role, access subsystem 110 may determine whether the access right allows access to client identifying data. In an implementation, in response to a determination that the access right does not allow access to client identifying data, access subsystem may be programmed to assign (or enable) the access right to/for the role (for which the corresponding application is requested). In another implementation, in response to a determination that the access right does allow access to client identifying data, access subsystem may be programmed to work with remediation subsystem 112 to assign (or enable) the access right or an alternative access right to/for the role or an alternative role. [036] In an implementation, remediation subsystem 112 may be programmed to receive information indicating interactions (or interaction types) intended or otherwise planned for roles associated with a project from role subsystem 108, and/or to receive information regarding access rights related to applications that are requested for the roles from access subsystem 110, such as whether the access rights allow access to client identifying data. Examples of other information that may be received from role subsystem 108, access subsystem 110, or other subsystems may comprise applications or access rights that have already or previously been assigned to (or enabled for) the roles, users assigned to the roles, tasks assigned to the roles, processes assigned to the roles, objectives assigned to the roles, the client (or entity/entity type) that is identified by client identifying data to which the access rights allow access, etc. The received information may, for example, be utilized as factors to assess whether an access right of an application requested for a role should be assigned to (or enabled for) the role (e.g., if the access right allows access to client identifying data), whether an alternative access right should instead be assigned to (or enabled for) the role, whether the role should be limited before assigning (or enabling) the access right or the alternative access right for the role, whether alternative roles should be created to supplement or replace the role, etc.

[037] In an implementation, remediation subsystem 112 may be programmed to provide the assessments regarding whether access rights of applications requested for roles or alternative access rights should be assigned to (or enabled for) the roles or alternative roles. In an implementation, the assessments may be provided to one or more administrators, managers, or other relevant users to assist those users in determining whether the access rights or the alternative access rights should be assigned to (or enabled for) the roles or the alternative roles. In one use case, for instance, final approval may be required from one or more administrators, managers, or other relevant users before an access right may be assigned to (or enabled for) a role, an alternative role is created (e.g., limiting of a role, creation of a new role to supplement a limited role or to replace a role, etc.), or other action requiring administrative or managerial approval is taken. [038] In an implementation, a determination may be made to limit a role to one or more domains, such as logical domains (e.g., user groups, organization divisions, organizations, etc.) or physical domains (e.g., jurisdictions, geographical areas, etc.) based on a determination that an access right of an application requested for the role allows access to client identifying data.

[039] By way of example, due to laws of various jurisdictions, organizations or other entities may face high civil penalties or even criminal charges if client identifying data handled by the organizations or other entities are transmitted outside the respective organization, outside a certain jurisdiction, etc. (e.g., intentional or unintentional release of CID by an employee or contractor). As such, in one use case, a role may be limited before an access right allowing access to client identifying data is assigned to (or enabled for) the role such that the role is not intended to (or otherwise planned for) interactions external to the organization, external to the jurisdiction, etc.

[040] In an implementation, remediation subsystem 112 may be programmed to work with role subsystem 108, access subsystem 110, or other subsystems to limit the role to one or more domains in conjunction with enabling the access right for the role (e.g., in response to a determination that the access right allows access to CID, in response to a determination that the access right allows access to CID of a particular client or client type, etc.). As an example, role subsystem 108 may be programmed to limit the role to the domains, and access subsystem 110 may be programmed to enable an access right (of an application requested for the role) for the limited role. In one use case, a role may be limited to a domain by removing a part of the role that is intended for interaction that is external to the domains. In another use case, a role may be limited to a domain by creating a new role that comprises a part of the original role that is not intended for interaction external to the domains and limiting the original role to the new role.

[041] In an implementation, role subsystem 108 may be programmed to create one or more "new" roles to supplement or replace a role. For example, a particular project role may comprise a first part that is not intended for interaction external to one or more domains (e.g., outside an organization, outside a jurisdiction, etc.) and a second part that is intended for interaction external to the domains. When an access right of an application requested for the project role allows access to client identifying data, the project may be modified such that new roles are created for the project to supplement or replace the original project role. As an example, the project may be modified such that first and second roles are created such that the first role comprises the first part of the original role that is not intended for interaction external to the domains and the second role comprises the second part of the original role that is intended for interaction external to the domains. The first role may, for instance, comprise the first part of the original role without the second part of the original role, and the second role may comprise the second part of the original role without the first part of the original role. As such, in an implementation, role subsystem 108 may limit the original role to the domains by limiting the original role to the first role. It should be noted that, in some implementations, the creation of a "new" role may comprise a modification of an original role such that the modified role is "new" with respect to a project even though role identifiers associated with the original role and the modified rule are the same. In other words, a "new" role may be created for a project by modifying an available role associated with the project.

[042] In an implementation, when a first access right that allows access to client identifying data is requested, but cannot be assigned to (or enabled for) a role that is intended for interactions external to one or more domains (e.g., outside an organization, outside a jurisdiction, etc.), the role may be limited to the domains before the first access right is enabled for the role. Limiting of the role may, however, leave open a project need that the original role was previously created to address. As such, at least a second role may be created for the project to supplement the limited role. If, for instance, the second role is intended for interactions external to the domains, a second access right that does not allow access to client identifying data (and that facilitates the second role in addressing the project need left open by the limiting of the original role) may be determined and enabled for the second role. Thus, the limited role may have access to client identifying data but is limited to the domains, while the second role may address one or more project needs that cannot be addressed by the limited role such as project needs involving external interactions that do not require access to client identifying data. In this way, interactions involving client identifying data may be limited to the domains (e.g., limited to interactions within an organization, limited to interactions within a jurisdiction, etc.)

[043] In an implementation, an alternative access right may be assigned to (or enabled for) a role in lieu of an access right of an application requested for the role. By way of example, if a first access right of an application requested for a particular project role allows access to client identifying data, remediation subsystem 112 may be programmed to inquiry whether one or more appropriate alternative access rights (e.g., of the same application or a different application) are available. In an implementation, an inquiry of whether a second access right that allows access to non-sensitive identifiers (or other information) that corresponds to the client identifying data accessible via the first access right is available may be effectuated. If the second access right exists, the second access right may be assigned to (or enabled for) the role in lieu of the first access right. The second access right may, for instance, allow access to a non-sensitive version of the client identifying data (e.g., a hashed version) accessible via the first access right, but may not allow access to the client identifying data. In this way, the number of roles that have access to client identifying data may be reduced, thereby increasing protection for client identifying data. In another implementation, an inquiry of whether a second access right that allows access to client identifying data associated with clients that have waived certain protections for their client identifying data (but does not allow access to other client identifying data) may be effectuated. As an example, if such a second access right exists, the second access right may be assigned to (or enabled for) the role in lieu of the first access right. In one use case, for instance, the second access right may allow access to client identifying data associated with clients that have signed waivers to allow offshore/outsourced data processing of their client identifying data. However, the second access right may not allow access to other client identifying data associated with other clients. In this way, only such "protection- waived" client identifying data may be accessed via the second/alternative access right.

[044] As shown in FIG. 2, system 200 may comprise user interface subsystem 106, role subsystem 108, access subsystem 110, remediation subsystem 112, role information repository 116, application information repository 118, or other components. Operations of the various subsystems or other components of system 200 may be implemented by one or more processing devices (e.g., a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information) associated with the subsystems or other components.

[045] In an implementation, as illustrated, user interface subsystem 106, role subsystem 108, access subsystem 110, and remediation 112 may work with one another and/or other components to perform the functions described herein. By way of example, user interface subsystem 106 may provide a user interface that facilitates assignment (or enablement) of access rights to roles while maintaining security of client identifying data. As an example, a user interface that is presented to a user may be programmed to enable a user to input role information, such as applications or access rights requested for the roles, users assigned to the roles, tasks assigned to the roles, processes assigned to the roles, objectives assigned to the roles, interactions (or the types of interactions) for which the roles are intended, or other information. In one use case, upon input of roles for a project, a user may be presented with a plurality of applications from which the user may select for a particular role (or roles). Information regarding available applications for the role may, for instance, be obtained from application information repository 118. Upon selection of an application for a role, access rights available via the application may be determined and presented to the user (e.g., based on application information obtained from application information repository 118). The user may, for instance, selected one or more access rights from the presented access rights to request that the selected access rights be assigned to (or enabled for) the role. [046] In an implementation, user interface subsystem 106 may store the role information in role information repository 116 so that the stored role information may later be processed by the appropriate subsystems (e.g., role subsystem 108, access subsystem 110, remediation subsystem 112, or other subsystems) to assigned (or enable) the requested access rights or alternative access rights to/for the indicated roles or alternative roles. In another implementation, upon receiving the role information via the user interface, user interface subsystem 106 may immediately initiate the processing of the role information by the appropriate subsystems so that the requested access rights or alternative access rights may be assigned to (or enabled for) the indicated roles or alternative roles (e.g., a limited version of the role, new roles created from the role, etc.).

[047] In an implementation, prior to assignment (or enablement) of an access right for a role, final approval may be required from an administrator, a manager, or other relevant user. As such, user interface subsystem 106 may be programmed to provide a request for a confirmation to one or more appropriate users. The users may thereafter utilize a user interface associated with user interface subsystem 106 to approve or deny the assignment (or enablement) of the access right for the role.

[048] FIG. 3 is an exemplary illustration of assignments of application access rights to project roles, according to an implementation of the invention. As shown in FIG. 3, role information repository 116 may store role information indicating roles and/or their associated tasks, processes, objectives, or other project aspects. In addition, the role information of role information repository 116 may indicate applications and/or access rights assigned to (or enabled for) the roles. As further shown, the indicated applications and/or access rights that are assigned to (or enabled for) the roles correlate to application information stored in application information repository 118.

[049] FIG. 4 is another exemplary illustration of assignments of application access rights to project roles, according to an implementation of the invention. As shown in FIG. 4, the "Securities Transformation" project may comprise at least three processes (e.g., "Scrubbing," "Cleansing," and "Notification"). In one use case, the plan for the project may be to outsource at least some of the "Cleansing" process to one or more organizations outside of a particular jurisdiction in which the organization managing the overall project resides. If, for instance, the jurisdiction of the managing organization (or the jurisdictions to which at least some of the "Cleansing" process is outsourced) has laws against transmission of client identifying data, the access rights requested for a role associated with the "Cleansing" process may need to be analyzed (e.g., to determine whether the access rights allows access client identifying data). Based on such analysis, the appropriate measures may be taken as described herein elsewhere.

[050] FIG. 5 is an exemplary illustration of a flowchart of a method for managing application access rights of project roles, according to an implementation of the invention. The operations of method 500 presented below are intended to be illustrative. In an implementation, method 500 may be accomplished with one or more additional operations not described, and/or without one or more of the operations discussed. Additionally, the order in which the operations of method 500 are illustrated in FIG. 5 and described below is not intended to be limiting.

[051] In an implementation, method 500 may be implemented in one or more processing devices (e.g., a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information). The one or more processing devices may include one or more devices executing some or all of the operations of method 500 in response to instructions stored electronically on an electronic storage medium. The one or more processing devices may include one or more devices configured through hardware, firmware, and/or software to be specifically designed for execution of one or more of the operations of method 500.

[052] At operation 502, role information associated with a project may be obtained. Operation 502 may be performed by a role subsystem that is the same as or similar to role subsystem 108, in accordance with one or more implementations . [053] At operation 504, applications that are to be used by the roles (indicated by the role information) may be determined. Operation 504 may be performed by an access subsystem that is the same as or similar to access subsystem 110, in accordance with one or more implementations.

[054] At operation 506, an access right available via one of the applications (that is to be used by one of the roles) is determined. Operation 506 may be performed by an access subsystem that is the same as or similar to access subsystem 110, in accordance with one or more implementations.

[055] At operation 508, a determination of whether the access right allows access to client identifying data is effectuated. Operation 508 may be performed by an access subsystem that is the same as or similar to access subsystem 110, in accordance with one or more implementations. Responsive to a determination that the access right allows access to client identifying data, method 500 may proceed to operation 510. Responsive to a determination that the access right does not allow access to client identifying data, method 500 may proceed to operation 512.

[056] At operation 510, the role may be limited to one or more domains. The role may, for example, be limited to the domains in response to a determination that the access right allows access to client identifying data. Operation 510 may be performed by a remediation subsystem that is the same as or similar to remediation subsystem 112, in accordance with one or more implementations.

[057] At operation 512, the access right may be enabled for the limited role. Operation 512 may be performed by an access subsystem that is the same as or similar to access subsystem 110, in accordance with one or more implementations.

[058] At operation 514, the access right may be enabled for the role (e.g., without limiting or otherwise modifying the role). The access right may, for example, be enabled for the role in response to a determination that the access right does not allow access to client identifying data. Operation 514 may be performed by an access subsystem that is the same as or similar to access subsystem 110, in accordance with one or more implementations.

[059] FIG. 6 is an exemplary illustration of a flowchart of a method for creating and/or modifying roles to maintain security of client identifying data and/or adherence to regulatory requirements related to client identifying data when enabling application access rights for roles, according to an implementation of the invention. The operations of method 600 presented below are intended to be illustrative. In an implementation, method 600 may be accomplished with one or more additional operations not described, and/or without one or more of the operations discussed. Additionally, the order in which the operations of method 600 are illustrated in FIG. 6 and described below is not intended to be limiting.

[060] In an implementation, method 600 may be implemented in one or more processing devices (e.g., a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information). The one or more processing devices may include one or more devices executing some or all of the operations of method 600 in response to instructions stored electronically on an electronic storage medium. The one or more processing devices may include one or more devices configured through hardware, firmware, and/or software to be specifically designed for execution of one or more of the operations of method 600.

[061] At operation 602, role information and application information (that are associated with a project) may be analyzed to determine an access right available via an application that is to be used by a role associated with the project. Operation 602 may comprise one or more of operations 502, 504, 506, or 508 of method 500 shown by FIG. 5, in accordance with one or more implementations.

[062] At operation 604, first and second roles may be created from the role. For example, the first and second roles may be created such that the first role comprises a first part of the role that is not intended for interaction external to one or more domains and such that the second role comprises a second part of the role that is intended for interaction external to the domains. The first role may, for instance, comprise the first part of the role without the second part of the role. The second role may comprise the second part of the role without the first part of the role. Operation 604 may be performed by a remediation subsystem that is the same as or similar to remediation subsystem 112, in accordance with one or more implementations.

[063] At operation 606, the role may be limited to the first role (comprising the first part of the role that is not intended for interaction external to the domains). Operation 606 may be performed by a role subsystem that is the same as or similar to role subsystem 108, in accordance with one or more implementations.

[064] At operation 608, the access right may be enabled for the limited role (or the first role). Operation 608 may be performed by an access subsystem that is the same as or similar to access subsystem 110, in accordance with one or more implementations.

[065] At operation 610, a second access right may be enabled for the second role. The second access right may, for instance, be an access right of an application that is to be used by the second role and does not allow access to client identifying data. As such, even though the second role may be intended for external interaction, the second access right (enabled for the second role) does not allow access to client identifying data. Thus, no security issues related to client identifying data are created from the enabling of the second access right for the second role. Operation 610 may be performed by an access subsystem that is the same as or similar to access subsystem 110, in accordance with one or more implementations.

[066] FIG. 7 is an exemplary illustration of a flowchart of a method for managing user selection of application access rights for project roles, according to an implementation of the invention. The operations of method 700 presented below are intended to be illustrative. In an implementation, method 700 may be accomplished with one or more additional operations not described, and/or without one or more of the operations discussed. Additionally, the order in which the operations of method 700 are illustrated in FIG. 7 and described below is not intended to be limiting.

[067] In an implementation, method 700 may be implemented in one or more processing devices (e.g., a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information). The one or more processing devices may include one or more devices executing some or all of the operations of method 700 in response to instructions stored electronically on an electronic storage medium. The one or more processing devices may include one or more devices configured through hardware, firmware, and/or software to be specifically designed for execution of one or more of the operations of method 700.

[068] At operation 702, a user input that indicates an application for a role may be obtained. For example, a plurality of applications may be presented to a user on a user interface so that the user can select one or more of the presented applications for the role. As such, the user input that is obtained may comprise a user selection of one of the presented applications. Operation 702 may be performed by a user interface subsystem that is the same as or similar to user interface subsystem 106, in accordance with one or more implementations.

[069] At operation 704, access information associated with the application may be obtained based on the user input that indicates the application. Operation 704 may be performed by an access subsystem that is the same as or similar to access subsystem 110, in accordance with one or more implementations.

[070] At operation 706, access rights associated with the application may be presented on a user interface based on the access information. For example, the obtained access information may indicate the access rights that are available via the application. As such, the access information may be used to identify the acc¾ss rights to be presented on the user interface. Operation 706 may be performed by a user interface subsystem that is the same as or similar to user interface subsystem 112, in accordance with one or more implementations.

[071] At operation 708, a user input that indicates one of the presented access rights for the role may be obtained. For example, a user may select one of the presented access rights for the role to initiate enablement of the selected access right for the role. As such, the user input that is obtained may comprise a user selection of one of the presented access rights. Operation 708 may be performed by a role subsystem that is the same as or similar to role subsystem 108, in accordance with one or more implementations.

[072] At operation 710, limiting of the role and/or enabling of the selected access right for the role may be facilitated. Operation 710 may comprise one or more of operations 506, 508, 510, 512, or 514 of method 500 shown by FIG. 5 with respect to the selected access right, in accordance with one or more implementations .

[073] FIG. 8 is an exemplary illustration of a flowchart of a method for maintaining security of client identifying data using alternative application access rights, according to an implementation of the invention. The operations of method 800 presented below are intended to be illustrative. In an implementation, method 800 may be accomplished with one or more additional operations not described, and/or without one or more of the operations discussed. Additionally, the order in which the operations of method 800 are illustrated in FIG. 8 and described below is not intended to be limiting.

[074] In an implementation, method 800 may be implemented in one or more processing devices (e.g., a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information). The one or more processing devices may include one or more devices executing some or all of the operations of method 800 in response to instructions stored electronically on an electronic storage medium. The one or more processing devices may include one or more devices configured through hardware, firmware, and/or software to be specifically designed for execution of one or more of the operations of method 800.

[075] At operation 802, role information and application information (that are associated with a project) may be analyzed to determine a first access right available via an application that is to be used by a role associated with the project. Operation 602 may comprise one or more of operations 502, 504, 506, or 508 of method 500 shown by FIG. 5, in accordance with one or more implementations.

[076] At operation 804, a determination that the first access right available via the application allows access to client identifying data may be effectuated. Operation 804 may be performed by an access subsystem that is the same as or similar to access subsystem 110, in accordance with one or more implementations.

[077] At operation 806, a second access right that allows access to non-sensitive identifiers (or other information) that corresponds to the client identifying data accessible via the first access right may be determined. For example, the second access right may be determined for the role in response to a determination that the first access right available via the application allows access to client identifying data. The second access right may, for instance, allow access to a non-sensitive version of the client identifying data (e.g., a hashed version) accessible via the first access right, but may not allow access to the client identifying data. As such, an alternative access right to the first access right may be determined for the role where the alternative access right does not allow access to client identifying data. Operation 806 may be performed by an access subsystem that is the same as or similar to access subsystem 110, in accordance with one or more implementations.

[078] At operation 808, the second access right (that allows access to the corresponding non-sensitive identifier) may be enabled for the role. For example, the second access right may be enabled for the role, and the first access right may not be enabled for the role. In one use case, for instance, a request to assign (or enable) the first access right for the role may be denied and/or modified such that the second access right is enabled for the role in lieu of the first access right. Operation 808 may be performed by an access subsystem that is the same as or similar to access subsystem 110, in accordance with one or more implementations.

[079] In an implementation, the various computers and subsystems illustrated in the Figures may comprise one or more computing devices that are programmed to perform the functions described herein. The computing devices may include one or more electronic storages (e.g., electronic storage 1 14, role information repository 116, application information repository 118, etc.), one or more physical processors programmed with one or more computer program instructions, and/or other components. The computing devices may include communication lines, or ports to enable the exchange of information with a network (e.g., network 120) or other computing platforms. The computing devices may include a plurality of hardware, software, and/or firmware components operating together to provide the functionality attributed herein to the servers. For example, the computing devices may be implemented by a cloud of computing platforms operating together as the computing devices. Each of the computers and subsystems may individually provide a given protective measure or may be combined with other computers and subsystems to together provide a combination of protective measures described herein.

[080] The electronic storages may comprise non-transitory storage media that electronically stores information. The electronic storage media of the electronic storages may include one or both of system storage that is provided integrally (i.e., substantially non-removable) with the servers or removable storage that is removably connectable to the servers via, for example, a port (e.g., a USB port, a firewire port, etc.) or a drive (e.g., a disk drive, etc.). The electronic storages may include one or more of optically readable storage media (e.g., optical disks, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard drive, floppy drive, etc.), electrical charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., flash drive, etc.), and/or other electronically readable storage media. The electronic storages may include one or more virtual storage resources (e.g., cloud storage, a virtual private network, and/or other virtual storage resources). The electronic storage may store software algorithms, information determined by the processors, information received from the servers, information received from client computing platforms, or other information that enables the servers to function as described herein.

[081] The processors may be programmed to provide information processing capabilities in the servers. As such, the processors may include one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information. In an implementation, the processors may include a plurality of processing units. These processing units may be physically located within the same device, or the processors may represent processing functionality of a plurality of devices operating in coordination. The processors may be programmed to execute computer program instructions to perform functions described herein of subsystems 106, 108, 110, 112, or other subsystems. The processors may be programmed to execute modules by software; hardware; firmware; some combination of software, hardware, or firmware; and/or other mechanisms for configuring processing capabilities on the processors.

[082] It should be appreciated that the description of the functionality provided by the different subsystems 106, 108, 110, or 112 described herein is for illustrative purposes, and is not intended to be limiting, as any of subsystems 106, 108, 110, or 112 may provide more or less functionality than is described. For example, one or more of subsystems 106, 108, 110, or 112 may be eliminated, and some or all of its functionality may be provided by other ones of subsystems 106, 108, 110, or 112. As another example, additional subsystems may be programmed to perform some or all of the functionality attributed herein to one of subsystems 106, 108, 110, or 112.

[083] Although the present invention has been described in detail for the purpose of illustration based on what is currently considered to be the most practical and preferred implementations, it is to be understood that such detail is solely for that purpose and that the invention is not limited to the disclosed implementations, but, on the contrary, is intended to cover modifications and equivalent arrangements that are within the spirit and scope of the appended claims. For example, it is to be understood that the present invention contemplates that, to the extent possible, one or more features of any implementation can be combined with one or more features of any other implementation.