How often should you perform an audit?

Let’s start with the basics. What is an audit?

An audit is an examination of an aspect of your business perfromed by someone independent of your organization.

There are a few important aspects in this definition. First off, being an examination of an aspect of your business, this allows to segment and inspect only specific elements. Thus, you have a financial audit, which deals with the financial reports including but botlimited to balance sheets, income statements and notes. Alternatively, but following the same general approach, you have IT Audits. These typically handle the infrastructure, policies and operations. An application/platform audit follows a similar approach, with a more restrictive scope revolving around a specific customized or un-customized application or platform.

The other important aspect is the entity that performs the audit. The idea of contracting this to someone independent of your organization is to provide an unbiased view. While internal audits can take place more often, and they could be part of every internal project adding new capabilities or upgrading existing capabilities to your platforms or applications, the audit performed by an external party goes a step further by analyzing and providing feedback from an external, unbiased perspective.

With the move to cloud platforms, and the cyclical schedule of updates and releases, the ability to perform platform/solution audits becomes even more relevant.

How should an application/platform audit look like?

Let’s look at a few of the important elements of an application/platform audit.

Start with the audit scope. The audit will be limited to a respective application/platform. You might want to exclude or limit from the scope 3rd party solutions over which there is no direct control (other than a recommendation to upgrade to a newer version if available). In addition, your audit could be limited to functionality, configuration, or customization, or a combination of these.

Next, the audit outcome is a report. You must identify and define who the target audience if this report is. This includes not only specific roles, but also the actual recipients. Based on the audience, you must produce the report in a manner that provides the best impact and results. Thus, if the target audience in non-technical, you should structure your report in an easy to read manner for a non-technical reader, and include in one or more appendix sections the necessary technical details.

Another group or category to be identified from the beginning is the responsible parties and responsibilities. This sets the stage from the beginning with regards to which parties are required to participate, and in what roles. This also decreases the risk of not having the necessary support when performing an application/platform audit.

Typically, your audit report will include a section describing the professionals involved in performing the audit, as well as the fact that the report expresses an unbiased opinion on the application/platform being audited.

The purpose of the audit should be clearly identified in this report. There could be multiple purposes for performing an audit. You could choose to perform an audit before a major upgrade, or perform regular audits for better application/platform performance and functionality.

The bulk of the report will be focused around the findings and conclusions. this is the output of the investigation, and should include all findings. These could be items like best practices, standards, deprecations, new functionality that can replace old processes and customizations, etc.

Typically, your report will include a listing of the limitations encountered during the audit process. This section should flag items like limited access to part of the application/platform, access to perform the audit only in a non-production environment, etc.

The audit report should also include a summary of the work performed. This is an itemized list of actions performed.

The recommendations area is one of the subjective section of the report, including a set of actions to be performed to correct the earlier identified findings. One or more solutions can be provided for each identified finding.

The executive summary is the closing conclusion, giving an overview of the points covered during the report. Some recipients of this report could refer to this section to find out if specific questions have been answered in the report.

Along with the report presented, there could multiple appendixes attached, as well as references to other separate reports, best practices and recommendations that should be considered along with the report results.

Finally, other aspect should include the date of the report, which is typically the date the report is issues, the period during which the audit took place, as well as the names of the individuals and entities responsible for this report.

With all this information, the questions remains: How often should you perform an application/platform audit?

Well, it depends. Let’s consider a cloud platform that’s extended to suit your organization business model. These platform will have an update cycle, as well as standard feature and functionality deprecation schedule. The volume of configurations and customizations are also playing an important role. These are items you should be taking into consideration. You want to allow enough time to correct issues before having your back against the wall and being forced into a new version that will break existing functionality. You will also want to reduce the amount of customization be leveraging new features that allow configuration to replace customizations.

Taking into consideration these aspects, your salesforce automation platform should be audited about once a year. You should compress this schedule if you are continuously providing updates and improvements.

How often is your application/platform audited? Leave a note below!