Continuous Monitoring Design

Continuous Monitoring Rollout – Development

Posted on Posted in Continuous Monitoring

Learn best practices of continuous monitoring development with use of ACL Analytic Exchange platform.


Technical overview

Each rollout of analytics should be supported by technical overview documentation including following information:

  • List of all the scripts and relations between them
  • List of the related files and parameters
  • Schedule of scripts (frequency)
  • Naming details (scripts / results)

Script commentary

Each script implemented as a Continuous Monitoring analytic should be properly documented inside using script comment function. Following elements of documentation are expected:

  • Repeated definition of script objective within the analytic header
  • Change log for script within the analytic header
  • Each logical step explained with plain non-technical language
  • Markings parts of script applicable for only ACL Analytics or only AX Core



Completeness, accuracy and timeliness controls

Each interface used for Continuous Monitoring should ensure if possible controls (manual or automatic) covering following areas

  • Completeness – assuring that all data from system is transferred to target system
  • Accuracy – assuring that data transferred between systems is not changed at any point (or at least restricting possibility to change it)
  • Timeliness – assuring that data is transferred on time according to schedule of extracts on source system and analytics on target systems.

In case of no possibility to introduce controls related to completeness and accuracy of data, additional mitigation controls should be considered to ensure that data will not be modified in any way between source system and Continuous Monitoring platform. Also, significant reliance is placed in such case on User Acceptance Testing to ensure that data extracts are complete and contain all accurate information.

Any problems with interface should be monitored and communicated on time to platform administrator.

Source data handling

Files – Every source data file should be kept on AX Core server for history and evidence purpose, with proper mechanism in place to avoid unnecessary repeated import of same data. Files that were imported should be properly marked (i.e. using file name change function).

Kept source data allows for easier troubleshooting as well as reruns in case of analytic errors.

Historical data files should be kept on a server for at least one year from analytic. Removal of older historical source data should be done periodically by platform administrator.

Tables – Imported data should be kept only if necessary in case of historical data usage through logic of analytic. Source data that is kept as file, and not used for history shouldn’t be stored as table to reduce storage requirements for analytics.



CM Platform Overview

Analytics should be developed first on ACL Desktop based on initial Source Data provided. Main analytic logic should be completed there. Once this phase of development is completed, analytics are moved to AX Core QA system for additional definition, configuration and testing. All testing activities should be completed based on analytics run on AX Core QA system. Direct changes of script on AX Core QA are allowed. All testing must be successfully passed before analytics are moved to AX Core PROD environment.

 AX Core data structure

Each implementation should be enclosed in separate engagement. Within engagement analytics should be grouped into activities representing logical areas. Every analytics should be properly named to allow for unique identification of it purpose and scope including reference ID and short descriptive name. Names of analytic should not exceed 31 characters to allow for easy extraction and opening of log files related to script.

Logical separation of scripts

Analytics should be logically split into scripts related to import, data preparation and tests. Scripts responsible for import should be divided as per data source. Few analytics sharing same source data should share script related for import. Same rule should apply for data preparation, as long as prepared tables are shared by several analytics. Import scripts should not handle more than one file type at once to ensure proper troubleshooting. Data preparation scripts should be also constructed based on one group of output data files.

Script definition

Each analytic should be properly defined as per AX Core analytic declaration syntax to ensure properly all assumed functional requirements.

  • Table names should include prefix clearly identifying what’s purpose of the table (SRC – for original source data, P – for prepared source data, T – for temporary table used during analytics, RSLT – for tables with final results)
  • Script name and purpose should be also properly reflected by declaration within script header (“//ANALYTIC”)
  • Any input files used as part of a script should be properly declared within the analytic header (“//FILE”)
  • Historical data and results data used as reference for other scripts or next analytic runs should be properly declared as table data retained in AX Core after completion of scripts (“//DATA”)
  • Result tables and files should be properly declared within the analytic header. Results should also include retention of log file for troubleshooting purpose (“//RESULT”)

Analytic parameterization

Every variable that might need to be change for troubleshoot reruns as well as frequent changes of process should be defined as parameter. Following potential parameters should be taken into consideration

  • Investigation period (including starting and/or ending dates)
  • Thresholds
  • Sample size
  • Scope exclusions
  • Aging definition

Default values of parameters should be used wherever possible to allow for easier reschedule activities. Parameters should be assigned to variables if are available. If not variables should be defined within the script – that allows scripts to be run on both ACL Analytics and AX Core.

All parameters intended to be used need to be properly declared within the analytic header (“//PARAM”)

Design of exceptions

Result tables should include all elements as defined by Functional Requirements and as needed based on analytic logic.

Table that is used as result and is intended to transfer to AX Exceptions or GRC Results as results should be double checked for compliance of:

  • Length of field name (no longer then 20 characters)
  • Type of the field (making sure that Unicode is used for every field except of dates and amounts)

Leave a Reply