Overview

Background

People share information via e-mail, text, chat, phone calls or other applications. Once trust is established between two people (whether given lackadaisically or with caution) information sharing can begin after exchanging phone numbers, addresses, or profiles. Theoretically, in this one-on-one communication between two people, you know who you are sending data to and they know who they are receiving data from. However, if trust is given too freely without validation, one or both actors may not be who they say they are.

In a world where data is shared between systems, the systems are the ones doing the sharing, not people.

The system trust factor is similar to people where if systems want to talk with each other to share information, they must first trust each other and prove who they say they. As is the case with people, if trust is too easily given, a “bad actor” could cause irreparable damage.

To help protect systems from “bad actors” or mistakes, the trust factor is built into each communication and must contain the following two aspects:

Some form of security handshake
A system-based identifier for “who is who”

Objective

To help fulfill Unified Compliance’s mission statement to be THE authoritative platform for regulatory content, control frameworks, and policy guidance, one of the initiatives is to build products and functionality that extend the usage beyond professional lexicographers and glossarists to include many additional users to allow them to contribute to UC’s content repository.

To facilitate information sharing while ensuring each contributors true identity, we will establish, publicize, share, and use a standardized account definition.

Persona’s

Note: personas are in process of being built. Once in place, the links will be provided to those personas.

UC Mapper (linguist, English major, attention to detail …)
UC Mapper Approver (linguist, subject matter experts, …)
Partner Contributor (expert in their software and processes, not a linguist, busy with other tasks …)
Customer Contributor (institutional organization knowledge, domain expert, not a linguist, likely minimal compliance knowledge …)

Success Metrics

List project goals and the metrics we’ll use to judge success

Goal

Metric

Establish and document a standardized account schema and publish it in grcschema.org

Review and attain sign-off from the GRC schema governing body

Establish a set of APIs that utilize the standardized account schema

A UC-written application can interact with the API Gateway to establish trust and then share information

Build a frontend application that utilizes the standardized account via a set of APIs

Mapper / UCH 2.0 can establish trust and share PlantUML data which updates the federated database

and / or

Compliance Dictionary can establish trust and share term definitions that update the compliance dictionary database or federated dictionary database (TBD)

Current Challenges / Limitations

There is no established standardized account definition and interaction for SaaS applications in general or for GRC solutions in particular. Nor does UC publish or use a standardized account mechanism for any of its existing applications including Mapper, Dictionary, or the UCF. With no agreed upon standardized account definition and interaction, it makes it unnecessarily complicated for systems and applications to easily communicate and share information with one another. In particular, third-party partner applications like AuditBoard and ServiceNow have limited direct integration with UCF.

Benefits

Establishing and utilizing a standardized account definition and interaction will:

Prove Unified Compliance as a thought leader in the GRC space
Make it easier for third-party applications to integrate with UC applications and will meet or beat third-party trust requirements
Set a standard for all future UC applications on how to establish trust in order to facilitate contribution

Subscription / Pricing / Billing Impacts

There is no direct monetization component tied to Standardized Accounts; however, content contributed by third parties to the public federated database and federated dictionary will need to be attributed to the person or organization that contributed the content for potential monetization. In addition, data usage will need to be tracked, specifically to users and accounts for billing purposes. Standardized accounts are an integral part of establishing who will be charged for usage and given credit for contribution.

Beta and Early Access

Alpha and Beta access must be made available to selected members of the UC mapping team as they are actively using existing UC applications. Testers can validate both the API Gateway as well as the Mapper / UC 2.0 application.

Partners such as AuditBoard and Service Now will be good candidates to test integration with their applications; however, until content is made available, the value for establishing trust with no actual sharing is minimal.

Risks and Assumptions

It assumed that third-party applications will have similar enough account requirements that they will be able to setup accounts (primarily using organizations, accounts, and users) that they can integrate directly with UC applications.

One risk is that the establishment of organizations, accounts, and users may create a confusing onboarding and login experience driving prospects and customers away. The onboarding and login user experience must be made easy yet thorough to establish trust.

Milestones and Phases

List the project milestones along with how that milestone can be successfully measured.

Number	Description	Success Measurement
	TBD

Product Requirements

Use Cases

Happy Day Scenarios

As a content contributor I am able to quickly set up my organization that I work for, the account that I wish to start using the software with, and my specific user details that will perform tasks such as researching terms and contributing content.

Rainy Day Scenarios

After I setup my organization, I realize I made some mistakes and want to change pretty much everything including the legal name, name, description, primary e-mail address, founded date, primary phone number, and primary address.
After I setup my organization, I realize I should have used a different domain and want to start over or swap out to a different domain. If I can’t change domains, then I need the existing organization to be deleted so that no one can mistakenly use it
After I setup my first account, I realize I made some mistakes and want to change pretty much everything including the name, primary phone number, and primary address
After I setup my user ID, I realize I made some mistakes and want to change pretty much everything including the first name, middle name, last name, and how I want to contribute.
After I setup my user details so that I can contribute content, I realize I made some mistakes and want to change pretty much everything including my name prefix, suffix, middle initial, phone number, address, social accounts., languages, and membership in groups, teams, and initiatives.

Requirements

Requirement	User Story	Importance	Jira Issue	Comments
Organizations				Reference to the GRCschema definition => GRCschema - Organization
Ability to create and setup a new Organization with all required information as identified in the standardized account definition				Includes: legal name, name, description, domain, phone number, email address, founded year, phone number, address, social address, and classifications (e.g., NAICS Code, SIC Code …)
Ability to update an existing Organization for all relevant information identified in the standardized account definition				Same as above
Ability to upload and change the Organization logo
Ability to delete of an Organization				If users can’t delete on their own, it is fine if UC deletes on their behalf
Accounts				Reference to the GRCschema definition => GRCschema - Account
Ability to create and setup a new Account with all required information as identified in the standardized account definition				Includes: name, phone number, and address
Ability to update an existing Account for all relevant information identified in the standardized account definition
Ability to upload and change the Account logo
Ability to delete of an Account				If users can’t delete on their own, it is fine if UC deletes on their behalf
Ability to invite additional users to an account
Ability to deactivate users assigned to an account
Ability to delete users from an account				If users can’t delete on their own, it is fine if UC deletes on their behalf
Ability to create, update, update, and delete Groups and add/remove users to those Groups
Ability to create, update, update, and delete Teams and add/remove users to those Teams
Ability to create, update, update, and delete Initiatives and add/remove users to those Initiatives



Register for mapper and gain access to profile and email
RBAC for at least admins vs others

Ability to create, update, and delete one or more accounts associated to an organization
Ability to create, update, and delete a user
Ability to associate / disassociate a user from an account
Ability to request / remove rights for a user to publish to the UC Federated Database
Multiple user names
Make one name primary
Remove all names but one
Define aliases
remove all aliases
phone numbers
email addresses
social media addresses
street addresses
teams
roles
contributor gating / approval governance
RBAC for at least admins vs others

Open Questions

List any open questions that come to mind throughout the lifecycle of this project

Question	Answer	Date Answered

Out of Scope / Future Functionality

List the known features that are out of scope for this project or might be revisited at a later time.

As is case with the assumptions, it is important to list these out so that architects and engineers can plan accordingly for these later updates.

Impacted Product Components

If this project is a component to other areas or an update to an existing product, specifically call out where this product will interact with other areas.