Package: Compliance

Compliance: Data Model & Setup

Data Model

Policies

Policy objects are the heart of the system and the hub for all of the other objects. A Policy can be a single concept such as:

"All computers used by employees must have updated Anti-virus software installed before accessing any Company Confidential information."

Policies can also be grouped together by relating them to a parent Policy, which is more abstract such as:

"Jobscience Information Security Policy"

These high-level policies may include hundreds of individual policies in a full hierarchy. There is no limit to the number of levels supported, but we recommend that you keep it relatively flat; ideally corresponding to the way your current written policies are structured.

For example, the Jobscience Information Security Policy is structured like the ISO Standard 27002:2013 Sections 5 through 18. Following this structure, there is a top-level policy to represent the entire InfoSec Policy and 13 Policies that represent the major sections of the ISO Policy, such as Network Security Management.

Each of these 13 policies has two layers below that. When written out, the policies appear to be a table of contents. Using the example of the ISO Policy, one branch of the tree is shown below with the level numbers in parenthesis:

Jobscience Information Security Policy (1)

• Network Security Management (2)

  • Systems and Network Access Controls (3)

    • Access Controls (4)

    • Accounts (4)

    • Regular Review of Access Controls (4)

    • Remote Access Authorization (4)

    • Revocation of Access (4)

The benefit of this structure is that a single policy at the bottom level can usually be written in a single paragraph and easily understood by the employees of the company. For example, Revocation of Access:

The Policy object in Compliance and its page layouts enable you to capture the information associated with a policy and place it into an appropriate structure for Approvals, Revision control, and all of the other phases of the policy's life cycle. Jobscience provides a set of stages that explicitly tracks the lifecycle of a policy:

• Drafted

• Reviewed

• Circulated

• Approved

• Published

• Archived

Your organization can define their own custom stages, if necessary, and replace the standard sets that come with the product.

In addition to the Policy object, there are six additional objects that enable you to manage the processes associated with your policies:

• Model Terms

• Requests

• Violations

• Actions

• Audits

• Logs
  

Model Terms

Model Terms provide language that should be included in contracts and the statement of policy on your public documents and websites.

We strongly recommend that you consult legal advice from a compliance consultant for definitions of your model terms.

Requests

Requests are a record of parties asking for action to be taken to enforce a policy, for example, a request to be removed from a mailing list. The key concept of a Request is to demonstrate to a regulator or auditor that you have a means for processing requests per your established policies. We recommend that you work with your legal counsel and/or consultants to develop request processes that ensure compliance with the prevailing regulations.

Like Policies, Requests have a lifecycle as well. When a request is made, it is marked Received and can be moved through Investigated and then marked Completed. The request is stored in an encrypted manner and is linked to actions and policies. A Request is a series of stages that can be updated by your administrator.

Since the Request is a standard Jobscience object, it can be used to trigger workflows or business processes when created or updated to a new stage. A workflow or business process can generate an Action to record the steps that are required to respond to the request.

Violations

Violations are a memorialization of a policy violation. The violation is linked to the policy and identifies what has occurred and who is responsible for a policy breach. Violations should be recorded and corrected per the guidelines provided by your legal counsel and/or consultants.

The key concept of a Violation is that it provides you with a basis for demonstrating to a regulator or auditor that you have a means for enforcing and correcting failures in your organization and to show that you have done so for any specific breach.

Violations should be followed up with an investigation and action plan to correct the violation and be closed out after the action has corrected the problem. Violations are created manually, but a workflow or business process can generate an Action to record the steps required to respond to the breach.

Actions

Actions are a record that your organization has done something to address a Violation or a Request per the guidelines provided by your legal counsel and/or consultants. The key concept of an Action is to demonstrate to a regulator or auditor that you have a means for recording actions per your established policies and that you have taken the appropriate action for a given Request or Violation.

Actions are linked to Requests and Violations and reflect the follow up activity to resolve any open issues regarding a policy.

Actions have a defined lifecycle as well. The default stages include:

• Under Review

• Active

• Completed

Administrators can modify stages to fit the process of your organization.

Audits

Audits are a record that someone has reviewed and/or acknowledged a policy. Audits enable a company to show that it has an active process for educating its workforce regarding defined policies and reviewing the policies to ensure they are actively reviewed.

Many policies will require that employees read and acknowledge certain policies when they are hired and throughout their employment on a regular basis. Audit records are designed to record this event.

Logs

Log objects are used to record all compliance-related activities for archive and reporting purposes. They are created using Process Builder Processes any time a Request, Violation, Audit, or Action record is created or modified. The permissions for Log records are limited to Create and Read for everyone in the org so that the logs may not be modified or deleted. This provides a safeguard against unauthorized changes or deletion of the other records. A Violation or Request record may be altered or deleted by a user for example, but a log of this record's creation and any subsequent edits will be stored in the Logs.

In addition, Request, Violation, and Action records use separate objects from one another to facilitate the business process automation. This makes it difficult to produce a report that combines them all in simple chronological order. Logs eliminate this challenge.

Setup

Step 1: Define and Provision Participants

As covered in the Overview, you should designate a team within your business to review, approve, and disseminate your policies. These team members should access the Compliance App as full users of Salesforce. Provision them as Users if they do not already have one.

Permission Sets are additive and multiple sets may be awarded to a single user. Give the Policy Author permissions to anyone who will author Policies. In general, Authors do not publish their own policies. Identify the approvers in the organization and give them the Policy Publisher Permission Set. If an individual both authors and publishes, they can be awarded both Permission Sets.

• Policy Author

• Policy Publisher

• Compliance Manager

• Compliance Auditor

A Compliance Manager is the role that receives requests and issues violations. The people in that role will also be responsible for reviewing actions and following up on the ones carried out by others.

A Compliance Auditor is responsible for ensuring all employees have acknowledged the active policies when they are hired, when policies are updated, and to reconfirm they are still in compliance on a regular basis.

Step 2: Review and Enable Processes

There are several aspects to the built-in automations that should be reviewed before deploying this App.

The first aspect is related to the stages defined for the objects of the package. Policies, for example, use a default set of stages beginning with Drafted, Reviewed, and Circulated. The Compliance team should review the stage values for each of these objects and determine if any changes are required. Stages may be added, removed, or renamed for each object. Note that making changes to these stages may require changes to the associated Business Processes.

Once the stages are confirmed, the team should review and understand the automations defined by the App. These can be grouped by:

• Approval Processes

• Flows

• Process Builder

• Object Triggers

Determine if your organization wants to implement formal Approval Processes for policy review and publication. These processes are very specific to your organization, so none are defined out of the box.

"Self-Audit" is the only Flow defined out of the box. It is responsible for displaying this element on the home page. It is designed to present a list of policies that must be reviewed and acknowledged by the user.

There are several Process Builder Processes that are associated with Logs. This is where the new Log records are created each time a new record is created or a change occurs. Logs are very powerful, but over time will consume storage space. With normal activity, these logs should not grow too large too fast, but over time they may require attention. Determine if the Logging feature is appropriate for your company and if all of the entities should be logged. If the team decides that one or more of the entities are not required in the logs, deactivate the associated Process to prevent logs from being created.

Step 3: Define Policies

You can create a policy by selecting the Policy tab and then clicking the New button.

A dialog box displays asking you to complete information about the policy. Take a moment to complete the information fields as fully as possible. Define a Policy Name that easily describes the policy and determine if this policy has a parent policy that it should be attached to. Provide a short summary that describes the policy.

Next, define the severity of a policy violation and define a custom list of resources that should be available to properly enforce and maintain the policy. In order to customize the application, an administrator can go into the Policy object and define the picklist options for resources that match your business. Then you should define any terms used repeatedly in the policy that require a clear definition.

Now take a moment to fully describe the policy and the procedures for the enforcement of the policy. This is important for providing guidance on how to execute the policy.

Please provide guidelines for the policy in order to assist employees and managers in the proper execution of their duties. Also define when the policy was drafted, effective, and issued into the policy of the business.

Please indicate if there is a revised date and any request that was the source of the policy creation. The system will designate a policy owner based on the individual who created or entered the information. Depending on your internal approval process there is a set of statuses to apply to the policy to ensure a proper approval and notification process has been followed in the creation of the policy.

Once you save your policy, it will appear with a flow that defines what status the policy has reached in your review and approval process. You can view the policy in a list-view or a Kanban to manage your review and policy action plan.

Step 4: Define Model Terms

You can now review which policies require model terms for your website and/or contracts.

From the policy, you can create a new model term to be used as a standard in the implementation of the policy. The model terms are defined to be used in clauses, documents, privacy statements, agreements, and checklists that are used for distribution to third parties. The model terms will provide a library of acceptable language to be used with external points of contact.

The below 2 steps are optional but important to the delivery of a successful Compliance Program.

Step 5: Create Your Employee Community

Employees who need to be aware of your policies, but are not active in the management of the policy, should access the information via a defined Employee Community. You should define the audit and review activity with your legal counsel and/or consultants.

Step 6: Create Your Consumer Community

It's important that you provide third parties with a way to make requests of your organization regarding policy requests. We recommend that you provide simple forms for individuals to make requests appropriate to your policies. You should define the request process and activity with your legal counsel and/or consultants.