Why You Shouldn’t Try to Build GRC Yourself in Salesforce

Let’s talk about why that is.

First, it’s important to understand that the foundation of GRC, including Risk Management, Compliance, InfoSec and Audit, is made up of opinions. These opinions are based on data of course, but a risk or control assessment consists of a review of the data and an opinion of whether the risk is within acceptable levels, or if the control is effective. That opinion is made by a person on a particular date at a point in time, and is, for the most part, forward looking. It is saying given what we have seen up until this point we will, or will not, be in a good position going forward.

For example, a typical regulatory compliance assessment statement would be something like: “As of June 30 we believe that we are in full compliance with Regulation ABC and here is our evidence,” or next quarter “As of September 30 we believe that we are mostly compliant with Regulation ABC, we have 3 action items that are scheduled to completed by year end, and then we will be in full compliance, and here is our evidence.”

The same holds true for Risk Management. “On April 5 we reviewed the data and believe that our risk exposure is within our risk appetite.” However, in Risk Management the data changes even quicker. Just two days later with new information that statement might read “On April 7, given recent events we have identified the need for urgent action.”

This oversimplifies the effort involved, but the intent of a GRC program is to review all the data you have, and make an assessment as to whether action is needed.

Assessments are Not a Built-in Salesforce Capability

So why can’t you do this natively in Salesforce or another platform that wasn’t designed for GRC? Because there is no concept of an assessment. So, what does an assessment look like at a data level?

An assessment is an instance of your data applied to a particular focus. It allows you to assess the risks and controls for a business unit. An organization often has more than one business unit, and each one is a little bit different. Even if they are supposed to all be the same, they may have different employees, or operate in different locations exposing them to different regulators and risks. Attributes that are common can be assessed once, but each difference will need to be assessed separately. This can get complicated.

In order to reduce the complexity of GRC across a large organization, every program starts with a content library. That library underpins all of the assessments to drive consistency and reduce the effort. In Resolver, when you launch an assessment, you can choose to rely-on work that was done in a different assessment that might be substantially similar. This improves the speed and accuracy of a risk assessment and ensures that the company’s risk maturity grows and develops over time. There is no comparable feature in Salesforce and hence that would need to be completely custom built by developers.

Now let’s come back to assessments changing over time.

When regulations change, new risks appear, action items are completed, or the business changes in any material way, the assessment of whether the business is covered, or needs to act also changes. An obvious recent example of this is all of the change that unfolded in 2020. Every few days we learned more about COVID and its impact, and risks changed, new policies and regulations emerged, organizations shifted to remote work, supply chains were interrupted. Risk and control assessments changed daily.

Transactional Records Compared to Temporal Records

In Salesforce and other similar platforms, data is transactional. Most of the data that is created follows some sort of process, and then is closed (e.g. a lead is created, may become an opportunity which hopefully becomes a sale). Throughout the lifecycle of the deal the price might change, the scope of the contract or even the contact person. Each of those updates changes the record. You could try to access historical data by combing through the audit trail, but that’s very tedious. You could try copying the opportunity every time it changes but you would make a mess of your data. In Salesforce you care deeply about the current status of your funnel, you don’t typically care what the funnel used to look like 3 months ago.

In GRC, changes are vitally important. What you thought in the past matters a lot. Reporting periods typically trail the actual date, so it’s necessary to report on what the data was at the end of the quarter. Also, if an incident occurs and you need to prove that your organization was doing the right thing at the time it occurred. You need to be able to rewind the clock and prove that on October 4 at 3:15 p.m. when this incident occurred, we had a control in place and were compliant with regulation that were in place at that time. You need to be confident that you were within your risk appetite.

You need to be able to say that you are not liable for the incident occurring. It is irrelevant if you are currently doing the right thing now, the only thing that matters is what was true historically on the date in question. If anything has changed since that time (controls, regulations, risks, business units, personnel, etc.) and you don’t have temporal assessments you are at risk.

Tracking Changes over Time: Snapshots

But can’t I just export a copy of my data to have a record of what it used to look like? Yes, but think about how quickly information changes. You would need to proactively snapshot the whole environment every time you made a change. You’re going to miss some. Or even if it was automated, you’re going to end up with an enormous pile of PDF’s or excel files to sift through. Isn’t that what you’re trying to avoid with a GRC system?

So how can you do this in Salesforce at all? You can hire developers to write code in Salesforce to automate copying of your data with snapshots. We know this because we use Salesforce for our Sales, Marketing and Services teams. It’s a great CRM and it handles many use cases, just not GRC.

In Salesforce you can write custom code to take snapshots of data at certain times. You have to be thorough; you have to be sure that you copy everything you might need. A reorg or an acquisition at some point in the future? Make sure you copy your full org structure. Did an employee leave? Make sure you have copies of all prior risk and control owners. A change in wording in one of your policies? Make sure you have all prior versions timestamped and approvals documented. The bottom line is that this approach depends on incomplete tools and ad-hoc processes to manage what is a critical piece of any risk and compliance program — a time-stamped view of an organizational risk practice with each change automatically captured and easily accessible.

Choosing a Solution Built for GRC

Yes, you can build a GRC program in Salesforce, if you are prepared to hire developers and pay a development team to design, build, debug and maintain custom code. That’s in addition to paying for additional Salesforce licenses across the organization in order to create a complete and company-wide risk view. Even then, you must be willing to dig through old snapshots and create your own analysis if and when you have an incident. You must be willing to forego a content library approach and start each risk assessment from scratch, manually sharing learnings and approaches across the company.

Although Salesforce is a powerful CRM tool, it is not the best approach for GRC. To run an effective GRC function you need the right software for the job. By that we mean a tool that is built to address the critically important and unique nature of temporal record-keeping, time-based assessments, and a collective central library that builds maturity into your risk process.