Audit evidencing systems, methods & apparatus

Abstract

Systems, methods, apparatus and computer readable media provide efficient, effective and continuous delivery of audit evidence and audit reports to customers in a scalable way, in particular, but not limited to international compliance standards associated with the provision of Software as a Service (Saas) platforms. In one aspect, a system defines one or more computer-implemented tests to demonstrate auditable compliance with one or more standards. The system comprises one or more processors in communication with one or more memories, one or more input devices and one or more output devices. The one or more processors are specifically configured to compile, in the one or more memories, an electronic library of specific requirements of one or more standards or the like received via the one or more input devices, translate and map the specific requirements to an electronic library of one or more master internal controls, and generate an electronic library of one or more internal control tests based on one or more of the master internal controls.

Description

TITLEAUDIT EVIDENCING SYSTEMS, METHODS & APPARATUS FIELD OF THE INVENTION

[0001] The present invention relates to audit evidencing systems, methods, apparatus and computer readable media. In particular, but not exclusively, the present invention relates to audit evidencing systems, methods, apparatus and computer readable media in relation to international compliance standards associated with the provision of Software as a Service (Saas) platforms.BACKGROUND TO THE INVENTION

[0002] As management of cyber security and privacy risks becomes ever more paramount to the running of any business, the ability for SaaS and Cloud providers to transparently describe and attest to internationally recognised compliance standards is critical to allowing businesses to adopt SaaS and Cloud based solutions underpinning their digital transformation agendas.

[0003] Customers of SaaS and Cloud providers are requiring audit reports more frequently and not just on annual cycles. The customers themselves are becoming ever increasingly subject to ad-hoc audit demands.

[0004] SaaS and Cloud enterprises are inherently complex businesses, leveraging many different systems and components to both deliver and operate their service.The technological rate of change within this industry is extremely high, meaning the use of systems and technologies will evolve at an uncommonly high rate. SaaS businesses also typically extend beyond the provision of domestic services to a global market and must take account of many jurisdictions and regulatory landscapes. This increases the scope and complexity of the documentation and attestation requirements.

[0005] Global cyber security standards, for example, vary greatly, focusing on different aspects of security and having differing approaches. Standards also change over time. Producing evidence to fulfil third-party audits is an expensive and time-consuming undertaking. Current and typical practices revolve around spreadsheets and documents involving significant human capital, cost and duration. This also feeds into the associated third-party costs required to conduct such audits.

[0006] This all presents significant complexities, costs and scale challenges when looking to meet and evidence international compliance standards in leading global cyber security, that are core to conducting a SaaS business.

[0007] It will be appreciated that such problems also exist in the documentation and attestation requirements for compliance standards domestically and internationally in other disciplines beyond SaaS and Cloud enterprises.

[0008] Further problems and challenges encountered when trying to satisfy and evidence compliance with standards are specified in the detailed description of the solutions provided by embodiments of the present invention.

[0009] The reference to any prior art in this specification is not, and should not be taken as, an acknowledgement or any form of suggestion that the prior art forms part of the common general knowledge.OBJECT OF THE INVENTION

[0010] It is a preferred object of the invention to provide a system and / or a method and / or an apparatus and / or computer readable media that addresses or at least ameliorates one or more of the aforementioned problems of the prior art and / or provides a useful commercial alternative.

[0011] In particular, it is a preferred object of the invention to provide a system and / or a method and / or an apparatus and / or computer readable media that enables the efficient, effective and continuous delivery of audit evidence and audit reports to customers in a scalable way that minimises third-party audit efforts and costs.SUMMARY OF THE INVENTION

[0012] The present invention relates to systems, methods, apparatus and / or computer readable media that provide the efficient, effective and continuous delivery of audit evidence and audit reports to customers in a scalable way, in particular, butnot limited to international compliance standards associated with the provision of Software as a Service (Saas) platforms.

[0013] In one form, although not necessarily the broadest form, the invention resides in a method of defining one or more computer-implemented tests to demonstrate auditable compliance with one or more standards, or the like, the method comprising: compiling an electronic library of specific requirements (SSRs) of one or more standards or the like; translating and mapping the specific requirements to an electronic library of one or more master internal controls (MICs); and generating an electronic library of one or more internal control tests (ICTs) based on one or more of the master internal controls.

[0014] In another form, although not necessarily the broadest form, the invention resides in a system to define one or more computer-implemented tests to demonstrate auditable compliance with one or more standards, or the like, the system comprising: one or more processors in communication with one or more memories, one or more input devices and one or more output devices, wherein the one or more processors are specifically configured to: compile, in the one or more memories, an electronic library of specific requirements of one or more standards or the like received via the one or more input devices; translate and map the specific requirements to an electronic library of one or more master internal controls in the one or more memories; and generate, in the one or more memories, an electronic library of one or more internal control tests based on one or more of the master internal controls.

[0015] In a further form, although not necessarily the broadest form, the invention resides in a computer readable medium having stored thereon computer executable code to define one or more computer-implemented tests to demonstrate auditable compliance with one or more standards, or the like, wherein the computer executable code is configured to, when executed:compile an electronic library of specific requirements of one or more standards or the like received via the one or more input devices; translate and map the specific requirements to an electronic library of one or more master internal controls; and generate an electronic library of one or more internal control tests based on one or more of the master internal controls.

[0016] Preferably, translating the specific requirements to the one or more master internal controls comprises translating an inherent intent of the specific requirements to a context to which it will be applied.

[0017] Suitably, the specific requirements of one or more standards or the like comprise criteria, controls and / or guidance to be complied with for compliance with the one or more standards or the like.

[0018] Suitably, the one or more internal control tests assess the design and effectiveness of the master internal controls.

[0019] Preferably, the method comprises one or more internal control test objects executing one or more of the one or more internal control tests.

[0020] Preferably, the master internal controls are an abstraction layer between the specific requirements of the one or more standards or the like and the one or more internal control tests.

[0021] Preferably, the master internal controls are human readable to allow display in one or more audit reports.

[0022] Preferably, each master internal control addresses a single evidencable item.

[0023] Preferably, the master internal controls are structured in a repeatable pattern to allow programmatic generation of the one or more internal control tests.

[0024] Preferably, the master internal controls are independent of one or more of the following relating to the one or more standards or the like: any particulars that relate to the specific requirements; a technology; a method; a person(s); time period; approach or the like.

[0025] Suitably, translating the specific requirements of the one or more standards or the like to the one or more master internal controls comprises:identifying and clarifying the inherent intent of the specific requirements; deconstructing the specific requirements into singular and specific requirements; mapping the deconstructed requirements to the context to which the requirements apply; and generating an initial candidate master internal control for each mapped specific requirement.

[0026] Suitably, for each initial candidate master internal control, where there is an existing, identically matching master internal control, the specific requirements of the initial candidate master internal control are mapped to the existing, identically matching master internal control.

[0027] Suitably, for each initial candidate master internal control, where there is an existing, similar master internal control, and an intent of the existing, similar master internal control meet the intent of the initial candidate master internal control, the existing, similar master internal control is adjusted and the specific requirements of the initial candidate master internal control are mapped to the adjusted existing, similar master internal control.

[0028] Suitably, for each initial candidate master internal control, where there is not an existing, identically matching or similar master internal control, or the intent of the existing, identically matching or similar master internal control does not meet the intent of the existing, identically matching or similar master internal control, the initial candidate master internal control is finalised and added to the electronic library of master internal controls and the specific requirements of the initial candidate master internal control are mapped to the finalised master internal control.

[0029] Suitably, each internal control test addresses a single test.

[0030] Suitably, each internal control test defines specific logic, a date and one or more actions required to execute a single test.

[0031] Suitably, each internal control test is independent of one or more, and preferably all of the following: technology; systems; data sources.

[0032] Preferably, each internal control test references, and declares as required, one or more internal control test object (ICTO).

[0033] Preferably, each internal control test object is declared with a single type which defines a form of the internal control test object.

[0034] Preferably, the method, system or computer readable medium further comprises a library of Compliance Data Objects (CDOs) comprising one or a plurality of CDOs to hold one or more of actual data, an expression, or point to an executable function, wherein each CDO is referenced by at least one internal control test object.

[0035] Preferably, the method, system or computer readable medium further comprises a library of Compliance Data Adaptors (CDAs) comprising one or a plurality of CDAs to provide stored data values abstracted away from any source system or technology layer, wherein each CDA services one CDO.

[0036] Preferably, the method, system or computer readable medium further comprises a Control Execution Object (CEO) register comprising one or a plurality of CEOs, each CEO enabling an internal control test to be executed by an Execution Engine (EE) multiple times, in multiple contexts to fulfil a given master internal control.

[0037] Preferably, the method, system or computer readable medium further comprises a Compliance Audit Interface (CAI) in communication with the master internal control library and audit data to return required audit data to third party audit systems on demand.

[0038] Further forms, aspects and / or features of the present invention will become apparent from the following detailed description.BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order that the invention may be readily understood and put into practical effect, reference will now be made to preferred embodiments of the present invention with reference to the accompanying drawings, wherein like reference numbers refer to identical elements. The drawings are provided by way of example only, wherein:

[0040] FIG. 1 is a diagram illustrating systems, methods and apparatus according to embodiments of the present invention;

[0041] FIG. 2 is a diagram illustrating relationships between specific requirements of multiple standards, an electronic library of master internal controls (MICs), anelectronic library of internal control tests (ICTs) and an electronic library of internal control test objects (ICTOs);

[0042] FIG 3 is a general flow diagram illustrating methods relating to the generation of master internal controls;

[0043] FIG 4 is a general flow diagram illustrating methods relating to the generation of internal control tests;

[0044] FIG 5 is a diagram illustrating the relationships between the ICT and ICTO libraries, compliance data objects (CDOs), compliance data adaptors (CDAs) and third party systems;

[0045] FIG 6 is a diagram illustrating the relationships between the ICT library, compliance execution object (CEO) register and the execution engines;

[0046] FIG 7 is a general flow diagram illustrating methods relating to the execution engine (EE);

[0047] FIG 8 is a diagram illustrating the function of the compliance audit interface (CAI); and

[0048] FIG 9 is a general flow diagram illustrating verification methods relating to the compliance audit interface.

[0049] Skilled addressees will appreciate that the drawings may be schematic and that elements in the drawings are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the relative dimensions of some of the elements in the drawings may be distorted to help improve understanding of embodiments of the present invention.DETAILED DESCRIPTION OF THE INVENTION

[0050] The present invention relates to systems, methods, apparatus and computer readable media that provide the efficient, effective and continuous management and delivery of audit evidence and audit reports to customers in a scalable way. Embodiments of the present invention will be described in relation to such management and delivery of audit evidence and reports in relation to compliance with standards, and in particular international standards, associated with the provision of Software as a Service (Saas) platforms. However, it will be appreciatedthat the present invention is not limited to the management and delivery of data for audit evidence and audit reporting for the purpose of compliance with such standards. Persons skilled in the art will appreciate that the present invention can be applicable to the management and delivery of data for audit evidence and reports for other purposes that will nonetheless fall within the scope of the present invention as defined by the accompanying claims.

[0051] FIG. 1 is a diagram illustrating an overview of systems, methods, apparatus and a computer readable media to perform a number of functions in relation to the management and delivery of audit evidence and audit reports, in particular in relation to compliance with standards, and more particularly for compliance with international standards associated with the provision of Software as a Service (Saas) platforms.

[0052] According to one aspect, FIG. 1 illustrates an overview of systems, methods, apparatus and a computer readable media to define one or more computer- implemented tests to demonstrate auditable compliance with one or more standards, or the like according to embodiments of the present invention.

[0053] The system 100 to define one or more computer-implemented tests to demonstrate auditable compliance with one or more standards, or the like comprises one or more processors in communication with one or more memories, one or more input devices and one or more output devices, wherein the one or more processors are specifically configured to perform a number of special purpose functions. The one or more processors, one or more memories, one or more input devices and one or more output devices can be implemented in one or more computing devices situated locally or in a distributed manner.

[0054] The system 100 accesses one or more sources, typically external sources, of one or more standards or the like, such as international compliance standards 110. Such sources of standards can form part of the system of the present invention, but in most embodiments, such sources are external and are managed and kept up to date by the respective organisations responsible for such standards. FIG 1 shows examples of standards such as, but not limited to ISO, ATC-205 (SOC 2), IRAP (AU) FedRAMP (US), EU GDPR. This illustrates the domestic and international nature of such standards, and an indication of the variety and complexity involved in compliance.

[0055] The system 100 comprises one or more internal controls and tests 120, such as one or more master internal controls (MICs) and one or more internal control tests (ICTs), which are described in detail herein.

[0056] The system 100 provides a highly structured and codified system and method 140 of mapping internally defined control tests (ICTs) to data, expressions and functions / algorithms that can be utilised by execution functions, against the compliance data or other defined processes, to derive required audit and evidence results for prescribed MICs. This also includes the ability to bring in data from external or 3rdparty systems to be utilised in those processes. For example, data adaptors can obtain and adapt data from sources such as, but not limited to documents, cloud services, monitoring systems and log files for storage in a data store and for use by test objects, such as one or more internal control test objects (ICTOs), which are described in detail herein.

[0057] The system 100 comprises one or more control execution objects (CEO) 130. Embodiments of the invention include a disciplined and codified system and method of mapping the ICTs to data, rule sets and algorithms that can be utilised by Audit Execution Engines (EE) to execute the ICTs to derive required audit and evidence results sets, which are described in detail herein. The execution of these tests must be dynamic, highly scalable and resilient. Audit activities can be heavily clustered around specific dates and times such as the end of month, when a great many activates will be scheduled. These may also be required to complete within specified time periods so as to not disrupt other activities or in time for the next phases of audit activities. The execution system must be able to scale effectively to accommodate such surge activities. Current cloud technologies perfectly fit this requirement.

[0058] The system 100 comprises a Compliance Audit Interface (CAI) 150, which is concerned with the ability to provide and publish the evidence to auditors to satisfy that the MICs have been met. Traditionally spreadsheets and documents have been used to provide such information, which is very manual, human intensive and time consuming. In contrast, the present invention provides programmatic interfaces to allow evidence to be requested remotely by trusted third parties 160 when and as required. Third party audit firms can programmatically interrogate the system 100 to test and validate compliance controls within the context of a given compliance standard. This aspect of the invention allows third party audit firms to perform, forexample, a remote API type enquiry against a given compliance standard (ISO, SOC etc.) and a specific MIC for that standard, utilising the outputs of the MIC-CEOs, as described in detail herein.

[0059] With reference to FIG 2, according to some embodiments, the one or more processors are specifically configured to compile, in the one or more memories, an electronic library 220 of specific requirements of one or more standards or the like, such as international compliance standards 110, received via the one or more input devices or sources. Such requirements may be referred to as Standard Specific Requirements (SSRs). The one or more processors are also specifically configured to translate and map the specific requirements of the one or more standards 110 to an electronic library 230 of one or more master internal controls (MICs) in the one or more memories. The one or more processors are further specifically configured to generate, in the one or more memories, an electronic library 240 of one or more internal control tests (ICTs) based on one or more of the master internal controls.

[0060] Correspondingly, embodiments of the present invention are directed to a method of defining one or more computer-implemented tests to demonstrate auditable compliance with one or more standards, or the like, the method being implemented in the system. According to some embodiments, the method comprises compiling the electronic library 220 of specific requirements of one or more standards or the like, translating and mapping the specific requirements to the electronic library 230 of one or more master internal controls and generating the electronic library 240 of one or more internal control tests based on one or more of the master internal controls.

[0061] Correspondingly, embodiments of the present invention are directed to a computer readable medium, and / or a plurality of computer readable media, having stored thereon computer executable code to define one or more computer- implemented tests to demonstrate auditable compliance with one or more standards, or the like. According to some embodiments, the computer executable code is configured to, when executed, compile the electronic library 220 of specific requirements of one or more standards or the like received via the one or more input devices. The computer executable code is also configured to, when executed, translate and map the specific requirements to the electronic library 230 of one or more master internal controls. The computer executable code is also configured to,when executed, generate the electronic library 240 of one or more internal control tests based on one or more of the master internal controls.

[0062] The aforementioned system, method and computer readable medium / media to define one or more computer-implemented tests to demonstrate auditable compliance with one or more standards, or the like deal with the cost and complexities inherent in complying with many and varied international compliance standards. International compliance standards contain a list of requirements (criteria, controls or guidance) that must be complied with to pass any audit and attain the given compliance standard. The aforementioned system, method and computer readable medium / media process the requirements to create a single master list of internal controls and then define tests to enable the demonstrable and auditable fulfilment of the internal controls. Each externally provided requirement (SSR) of the standards is translated and mapped to one or more internally developed controls (MIC) which are tested by one or more internally developed tests (ICT) through the use of internally developed executable test objects (ICTO) stored in an electronic library 510 of one or more internal control test objects. One important step in developing the electronic library 230 of master internal controls to meet the standard requirements is translating the inherent intent of the requirements to the business context in which it will be applied.

[0063] The relationship between the electronic libraries 220, 230, 240, and their contents is shown in FIG 2 and summarised in Table 1 :

[0064] Table 1

[0065] According to some embodiments, the SSR library 220 comprises a plurality of SSRs for each standard, such as SSRs 1.1, 1.2, 1.3, ... , 1.x for standardIS027001 , SSRs 2.1 , 2.2, 2.3, , 2.y for standard ATC-205 and SSRs 3.1 , 3.2, 3.3, ..., 3.z for standard IRAP (AU).

[0066] According to some embodiments, the MIC library 230 comprises a plurality of MICs, such as MIC 1, MIC 2, MIC 3, ..., MIC x, each of which can relate to one or more SSR for one or more standards.

[0067] According to some embodiments, the ICT library 240 comprises a plurality of ICTs, such as ICT 1, ICT 2, ICT 3, ..., ICT x, each of which can relate to one or more MIC.

[0068] This specific configuration allows for complex mapping of multiple varied international compliance standards 110 to the library 230 of MICs and the subsequent feeding of downstream computing systems for test execution with the required definitions, rules and data. The electronic libraries 220, 230, 240 and mapping relationships are documented, stored and maintained within one or more computer systems, for example, one or more databases, and are electronically referenceable by other computing subsystems.

[0069] Various challenges are encountered by organisations working with and attaining a varied array of international compliance standards. For example, standards typically lag the technology curve and are written to reflect the believed / perceived technology capabilities of the time and audience for which they are intended. This presents an issue for leading edge technology vendors who have adopted the latest technology not considered when developing the standard. There are often significant amounts of overlap (causing duplication) in their requirements with other standards and the requirements can be expressed in very different terms and often through a different lens. Each Standard will contain a series of requirements that need to be evidenced and met to varying degrees to successfully attain compliance with the standard. To allow for broad application, some SSRs can be ambiguous or imprecise. Therefore, it is critical to determine the ‘intent’ of the requirement rather than relying on the literal wording. As standards evolve over time and change to meet emerging best practice requirements, new versions are released which modify, deprecate or include new requirements.

[0070] The following SSRs from three different international compliance standards, whilst inherently very similar, provide an example of some of the above points.

[0071] ISEA 3402 - Exposure Draft, 5.2.4 - establishes relevant security management process control activities. Management selects and develops control activities that are designed and implemented to restrict technology access rights to authorized users commensurate with their job responsibilities and to protect the entity’s assets from external threats.

[0072] Cloud Control Matrix - IAM-05 - User access policies and procedures shall be established, and supporting business processes and technical measures implemented, for restricting user access as per defined segregation of duties to address business risks associated with a user role conflict of interest.

[0073] ISO 27001 - 9.1 - Business requirement of access control: 9.1.1 - Access control policy; and 9.1.2 - Access to networks and network services.

[0074] In preferred embodiments, SSRs are stored within a suitable library mechanism, are assigned a unique ID, are mapped to a specific standard and have a status value, such as Active or Suspended.

[0075] Master Internal Controls (MICs) are a human readable abstraction layer between the SSRs and the very specific Internal Control Tests (ICTs) in the electronic library 240. MICs are developed to allow the mapping of many and varied SSR’s to the Master Internal Control library 240 that then allow subsequent systems to be derived to demonstrate the fulfilment of these controls.

[0076] MICs are the audited entities and hence items that compliance is reported against. Execution of all following described activities is done in the context of fulfilling a given MIC. Each MIC will have a unique MIC ID that will be referenced by execution functions and evidence logged for that MIC. All MICs will be assigned a unique MIC ID number and a status value, such as Active or Suspended.

[0077] In defining each MIC, a core set of engineering principles must be complied with. Each MIC must be singular and simple in that it must address no more than a single evidencable item and be expressed in the simplest possible way. This will maximise reuse and reduces duplication. Each MIC must be specific in that it is very concisely defined to meet the specific intent of the SRRs they map to within the business context to which it applies. For example, where security control SSRs have been developed based on the assumption that they will be applied to a service with a ‘data centre’ and legacy security technologies, it is imperative for a SaaSenvironment, that the ‘intent’ of the SSR is established to form the basis of the MIC. Each MIC must be human readable and in plain English, or other applicable language, to allow display, i.e. in Audit reports. Each MIC must be in a structured format following repeatable patterns, thus allowing the programmatic generation of ICTs. This allows the automatic and systematic feeding of downstream systems.Each MIC must be agnostic of any specifics that relate to a SSR, technology, method, person(s), period or approach etc.

[0078] Methods of translating an SSR into one or more MIC in accordance with embodiments of the present invention will now be described with reference to FIG 3. There are two primary scenarios where the translation of an SSR into a MIC may be undertaken. One scenario 300 is when a business adopts a new international compliance standard. Another scenario 305 is when criteria, controls or guidance within an international compliance standard already attested to by the business are amended or updated. In either case, the amended or new SSRs should be reviewed and listed, for example at 310, by creating a list of SSRs to be assessed, to enable an established systematic review process.

[0079] At 315, if there are no SSRs to be assessed, the review process ends. However, for each SSR to be assessed, the review process should be undertaken using the established MIC principles. This includes identifying and clarifying the intent of the SSR. At 320, the method includes deconstructing the SSR into singular and specific requirements, including into singular candidate master internal controls (MICs). The method can include assessing how the singular and specific requirements apply to the business context and translating the requirements to match. The method can include drafting an initial candidate MIC for each of the specific requirements.

[0080] At 330, the method includes comparing each candidate MIC to the existing MICs. At 340, the method includes determining if there is an identical match between the candidate MIC and the existing MICs. If there is an identical match, the method includes at 370 mapping the SSR to that existing MIC and moving to the next draft MIC. If there is not an identical match between the candidate MIC and the existing MICs, at 350, the method includes determining if there is a similar existing MIC. If so, at 360, the method includes determining if the existing MIC meets the same intent as the draft MIC and whether the existing MIC can be adjusted. If so, at 390, the methodincludes adjusting the existing MIC and mapping the SSR to the adjusted MIC. At 360, if the existing MIC does not meet the same intent as the draft MIC and the existing MIC cannot be adjusted, at 380, the method includes finalising the candidate MIC, adding the finalised MIC to the MIC library 230 and mapping the SSR to the finalised MIC. At 340, if there is not an identical existing MIC, and at 350, if there is not a similar existing MIC, at 380, the method includes finalising the candidate MIC, adding the finalised MIC to the MIC library 230 and mapping the SSR to the finalised MIC.

[0081] Some translation examples for the three SSR examples above will now be provided. To derive the MICs from the SSRs, the method includes analysing and determining whether the core intents of all three SSRs are that i) access to systems is restricted to those with suitable duties and responsibilities; and ii) there is a policy and procedures in place to manage access rights and any exceptions. The design of the MIC should be aligned with the business context within which it will operate. Therefore, using the intent of the requirements and the business context, the method includes creating a candidate MIC in alignment with the MIC Principles: “Core operational systems are monitored to verify for permissible and compliant access with exceptions being escalated for appropriate action.” Within this candidate MIC, a ‘compliant access’ test is created which follows the simple structure: (Item) (Action & / or Rule) (Item) else (Event), where:

[0082] Item = Core operational systems - which allows for these entities to be defined and managed elsewhere outside of the control, allowing the Item to be referenced by an Internal Control test (ICT).

[0083] Action & / or Rule = are monitored to verify for - there are many types of action or rules that can be applied and often in combination. Monitored and verify are agnostic of how, timing and specifics, thus allowing the how, timing and specifics to be built into the ICT.

[0084] Item = permissible and compliant access - where permissible allows for the definition of a permissible rule, i.e. who / what can access; compliant suggests a test for how access is performed; and access defines the action to be tested i.e. log on.

[0085] Event = exceptions being escalated for appropriate action - where exceptions can define what does and does not qualify as an exception; and escalated is an action to be undertaken.

[0086] Internal Control Tests (ICTs) stored in the ICT library 240 and Internal Control Test Objects (ICTOs) stored in the ICT library 250 will now be described in more detail.

[0087] ICTs are the specific tests that fulfil a given MIC. A MIC can map to one or more ICT. An ICT will reference one or more ICTOs. Where MICs need to be plain English, ICTs do not. However, ICTs must follow a defined structure and must reference ICTOs that are defined within the ICTO library 250. ICTOs will have different types, such as a list, a rule, an event etc. All ICTs will be assigned a unique ICT ID number and a status value, such as Active or Suspended.

[0088] The referencing of ICTOs allows the ICT to remain independent of systems or data sources, thus allowing the ICTOs to change without impacting the ICT. This is an important benefit as in technology organisations underlying systems change regularly and this would incur a significant maintenance overhead if not abstracted away via ICTOs.

[0089] The principles of the ICTs are as follows. ICTs must be singular in that they must address no more than a single test. This maximises reuse and reduces duplication. ICTs must be specific in that they must define the specific logic, date and actions required to execute a single test. ICTs are defined using ICTOs. ICTs must be agnostic of technology, systems and data sources. ICTs use ICTOs to remain agnostic. ICTs must have reference objects, i.e. they must reference and declare the required ICTOs.

[0090] An ICT example will now be described with reference to the candidate MIC example: “Core operational systems are monitored to verify for permissible and compliant access with exceptions being escalated for appropriate action.” Using this candidate MIC, the method includes establishing three relevant ICTs:

[0091] Core_Operational_Systems Only_Accessed_By_ Authorised_Staff else Escalate_Lvl_1

[0092] Core_Operational_Systems Only_Accessed_By Authorised_Systems else Escalate Lvl 1

[0093] Specific_Operational_Systems Must_Have Reason_Code else Escalate_Lvl_2

[0094] These three ICTs follow the simple structure of:

[0095] (ICT01 (type List)) (ICT02 (type Logic)) (ICT03 (type List)) else (ICT04 (type Event)

[0096] Where:

[0097] ICT01 = Core_Operational_Systems - this is an object in the ICTO library 250 and will have a type of ‘List’ i.e. a list of all core systems.

[0098] ICT02 - this is an object in the ICTO library 250 and will have a type of ‘Logic’, i.e. ‘if logon name does not equal’ which is testing for the exception.

[0099] ICT03 - this is an object in the ICTO library 250 and will have a type of ‘List’, i.e. a list of all authorised staff.

[0100] else = on exception (from the rule) execute the specified following Object.

[0101] ICT04 = Escalate_Lvl_1 - this is an object in the ICTO library 250 and will have a type of ‘Event’ i.e. generate alert level 1.

[0102] The method of generating the internal control tests (ICTs) based on one or more of the master internal controls MICs will now be described in more detail with reference to FIG 4. At 410, the method includes creating a list of MICs to assess. At 415, if there are no MICs / ICTs to be assessed, the review process ends. However, for each MIC to be assessed, the review process should be undertaken using the established MIC principles. At 420, the method includes deconstructing the MIC into singular and specific candidate ICTs. This may include referencing existing ICTOs for reuse or defining new ICTOs in the ICTO library 510.

[0103] At 430, the method includes comparing each candidate ICT to the existing ICTs. At 440, the method includes determining if there is an identical match between the candidate ICT and the existing ICTs. If there is an identical match, the method includes at 470 mapping the MIC to that existing ICT and moving to the next draft MIC to be assessed. If there is not an identical match between the candidate ICT and the existing ICTs, at 450, the method includes determining if there is a similar existing ICT. If so, at 460, the method includes determining if the existing ICT meets the same intent as the draft MIC and whether the existing ICT can be adjusted. If so,at 490, the method includes adjusting the existing ICT and mapping the MIC to the adjusted ICT. At 460, if the existing ICT does not meet the same intent as the draft MIC and the existing ICT cannot be adjusted, at 480, the method includes finalising the candidate ICT and ICTOs, and adding them to their respective ICT and ICTO libraries 240, 510. At 440, if there is not an identical existing ICT, and at 450, if there is not a similar existing ICT, at 480, the method includes finalising the candidate ICT and ICTOs, and adding them to their respective ICT and ICTO libraries 240, 510.

[0104] Hence, in some embodiments, translating the specific requirements of the one or more standards or the like to the one or more master internal controls comprises translating an inherent intent of the specific requirements to a context to which it will be applied.

[0105] In some embodiments, the specific requirements of the one or more standards or the like comprise criteria, controls and / or guidance to be complied with for compliance with the one or more standards or the like.

[0106] In some embodiments, the one or more internal control tests assess the design and effectiveness of the master internal controls.

[0107] In some embodiments, the method comprises one or more internal control test objects executing one or more of the one or more internal control tests.

[0108] In some embodiments, the master internal controls are an abstraction layer between the specific requirements of the one or more standards or the like and the one or more internal control tests.

[0109] In some embodiments, the master internal controls are human readable to allow display in one or more audit reports.

[0110] In some embodiments, each master internal control addresses a single evidencable item.

[0111] In some embodiments, the master internal controls are structured in a repeatable pattern to allow programmatic generation of the one or more internal control tests.

[0112] In some embodiments, the master internal controls are independent of one or more of the following relating to the one or more standards or the like: any particularsthat relate to the specific requirements; a technology; a method; a person(s); time period; approach or the like.

[0113] In some embodiments, translating the specific requirements of the one or more standards or the like to the one or more master internal controls comprises: i) identifying and clarifying the inherent intent of the specific requirements; ii) deconstructing the specific requirements into singular and specific requirements; ii) mapping the deconstructed requirements to the context to which the requirements apply; and iv) generating an initial candidate master internal control for each mapped specific requirement.

[0114] In some embodiments, for each initial candidate master internal control, where there is an existing, identically matching master internal control, the specific requirements of the initial candidate master internal control are mapped to the existing, identically matching master internal control.

[0115] In some embodiments, for each initial candidate master internal control, where there is an existing, similar master internal control, and an intent of the existing, similar master internal control meets the intent of the initial candidate master internal control, the existing, similar master internal control is adjusted and the specific requirements of the initial candidate master internal control are mapped to the adjusted existing, similar master internal control.

[0116] In some embodiments, for each initial candidate master internal control, where there is not an existing, identically matching or similar master internal control, or the intent of the existing, identically matching or similar master internal control does not meet the intent of the existing, identically matching or similar master internal control, the initial candidate master internal control is finalised and added to the electronic library of master internal controls and the specific requirements of the initial candidate master internal control are mapped to the finalised master internal control.

[0117] In some embodiments, each internal control test addresses a single test.

[0118] In some embodiments, each internal control test defines specific logic, a date and one or more actions required to execute a single test.

[0119] In some embodiments, each internal control test is independent of one or more, and preferably all of the following: technology; systems; data sources.

[0120] In some embodiments, each internal control test references, and declares as required, one or more internal control test object.

[0121] In some embodiments, each internal control test object is declared with a single type which defines a form of the internal control test object.

[0122] Another aspect of the invention 140 provides a highly structured and codified system and method of mapping internally defined control tests (ICTs) to data, expressions and functions / algorithms that can be utilised by execution functions, against the compliance data or other defined processes, to derive required audit and evidence results for prescribed MICs. This aspect also includes the ability to bring in data from external or 3rdparty systems to be utilised in those processes.

[0123] With reference to FIG 5, this is achieved by creating a library of Internal Control Test Objects (ICTO) 510 that is referenced by the ICTs in the ICT library 240. The ICTOs point to the specific data objects, expressions or functions and provide a range of additional metadata used to control the system. The ICTO library 510 can comprise one or a plurality of ICTOs, such as ICTO 1 , ICTO 2, ICTO 3, ... , ICTO x.

[0124] The system 100 can comprise a library of Compliance Data Objects (CDO) 520. The library of CDOs can comprise one or a plurality of CDOs. Compliance Data Objects 520 are used to hold either the actual data, an expression, or point to an executable function.

[0125] The system 100 can comprise a library of Compliance Data Adaptors (CDA) 530 comprising one or a plurality of CDAs, such as CDA 1 , CDA 2, CDA 3, ... , CDA x. Where data values are stored, a Compliance Data Adaptor 530 is used to provide those values and abstract away any source system or technology layer.

[0126] The key output is the construction and definition of a set of core libraries as described in Table 2.

[0127] Table 2

[0128] Internal Control Test Objects (ICTO) 510 in the ICTO library provide all of the foundational objects that are assembled to form executable tests. An ICT will reference multiple ICTOs. An ICTO will be declared with a ‘type’ which will define the ‘form’ of the ICTO.

[0129] One other key objective of the ICTO library is to abstract the controls and logic away from the actual systems, technologies and data sources that are being tested or utilised. This is important due to the complexities and the rate of change within IT systems. Many international compliance standard requirements are met by testing data from these systems to verify that certain conditions are met, e.g. only listed people can login. Hence, allowing the systems to change with minimal to no impact on the controls is important.

[0130] Hence, the ICTO’s do not contain the actual values, e.g. the list of Authorised User names, but point to the data object (database table name), expression or function to be used. This will also make the system considerably more portable and reusable should a change of implementation technology be required.

[0131] According to preferred embodiments, the ICTO principles are as follows.Each ICTO must comprise a Descriptor, which is a short narrative describing the purpose and contents of the ICTO. Each ICTO must comprise a Type. The Data Object contents must be of a type from a permissible list of ‘ICTO Types’. This should be an extensible list of types to allow for the evolution of such systems. Examples of Initial types are: LIST - a list of values; LOGIC - a definition of an expression or logic; EVENT - a computer program that performs a specific action; ALGORITHM - a computer program that is capable of performing some computational analysis against a given set of data. Each ICTO must also be Singular in that it must have a single type and the contents the ICTO references must be consistent with that type.

[0132] Examples of ICTOs are provided in Table 3:

[0133] Table 3

[0134] Example 1 : This example defines a ‘LIST’ type that contains a list of operational systems. This list is stored within the Oatalake.Dbname.Core_Op_Sys’ data store.

[0135] Example 2: This example defines a ‘LOGIC’ type that contains a logic statement defined within ‘Logic. OnlyAcessedByO’. This logic will reflect something in the way of ‘must be one of the following’.

[0136] Example 3: This example defines a ‘LIST’ type that contains a list of authorised staff. This list is stored within the ‘Datalake.Dbname.authorised_staff data store.

[0137] Example 4: This example defines a ‘EVENT’ type that identifies a function defined within ‘Event. Escalate_Alarm_Lvl_1()’. This event will initiate an alarm in a secondary system for example.

[0138] With further reference to FIG 5, the system 100 comprises a library of Compliance Data Objects (CDO) 520. CDOs contain all the actual data values, expressions, functions or algorithms that are referenced by ICTO’s. This layer standardises the technical presentation of these objects and abstracts away the very many and varied technical sources of data, information, function or programs. This technical abstraction layer minimises the impact of changes from 3rdparty systems 540 or downstream technologies. It also provides the ability to integrate manual data creation that will exist in many enterprise organisations, such as a manually updatedspreadsheet. A CDO will present this information in a standardised and consumable form.

[0139] 3rdparty engineering tools 540 may be used to create an algorithm, for instance AI / ML technologies may provide learning algorithms that will continually run and learn from data being provided to identify patterns of noncompliance or may provide a logical expression that can be simply executed against a given set of data. This will be invoked by a given CDO in a standardised way.

[0140] A CDO may provide an integration to invoke a 3rdparty alert or notification system should an ICT be used in a real time monitoring capacity as per ‘Event. Escalate_Alarm_Lvl_1 ()'.

[0141] The CDO library 520 is a technical layer and hence technology choices should be made as to the technologies that best fit the CDO technical presentation needs. For instance, data values may be stored within industry standard SQL databases. Functions and algorithms may be developed in specific programming languages. Expressions and logic likewise in an array of technologies.

[0142] According to preferred embodiments, the CDO principles are as follows. CDOs are Minimal in that a CDO is not intended to replicate all data in external systems, it is intended to store the absolute minimum required. CDOs are Highly Secure because there is potential for sensitive information to be stored within a CDO. Whilst every effort should be made to avoid and minimise this, the storage layer should be highly secure.

[0143] With further reference to FIG 5, the CDAs in the library of Compliance Data Adaptors (CDA) 530 are the interfaces and processes by which data and information from the various systems 540, such as system 1 , system 2, system 3, ... , system x, are received, extracted and stored within the Compliance Data Object library 520 in a verified and standardised format. These then populate the CDO’s in CDO library 520 that are referenced by ICTO’s in the ICTO library 510.

[0144] There will be many varied systems that form part of the compliance scope. These will utilise very different technologies, present information and data in many different ways, behave differently, and also be highly interchangeable as is the nature of modern businesses. Thus, the primary objectives of the CDAs are to: Extract or receive the required information and transform into a standardised CDO; Abstractaway the systems variances and technologies, allowing seamless 3rdparty or ancillary system or component change; Verify and log the action and provide notification of successful data handling / availability.

[0145] The CDA library 530 is a technical layer and hence technology choices should be made as to the technologies that best fit the CDA technical needs. By way of example, data may need to be read from 3rdparty data stores with a very specific technical access method, a static wiki page may need to be captured, and / or data may be pushed, hence the CDA is a receiver waiting for an event.

[0146] All CDAs log to a single CDA log target so all activities are recorded. Events and notifications can be driven for this. The logging will be used as part of the audit process to verify currency of information and execution of collection.

[0147] CDAs will need to execute at very different frequencies and periods. Thus, some form of scheduling mechanism is required based on implementation technology choices. Some CDAs will be continuously running, such as those listening or waiting to receive data, whereas others may execute on a daily, or weekly basis or other periodicity.

[0148] The CDA principles are as follows. The CDAs must be Highly Secure, i.e. they must ensure all information that is transported or moved is done so in a highly secure manner. The CDAs must be On Demand, i.e. a CDA may be invoked directly by an ICTO to gather the data in real time and on demand. The CDAs must have a frequency, i.e. the CDA should have a defined period of execution. The CDAs must be Singular, i.e. only service one CDO.

[0149] Another aspect of the invention focuses on the execution of the defined tests to produce audit evidence and results sets. The execution of the tests must be dynamic, highly scalable and resilient. Audit activities can be heavily clustered around specific dates and times such as the end of month, or after the end of a financial or calendar year, when a great many activates will be scheduled. These may also be required to complete within specified time periods so as to not disrupt other activities or in time for the next phases of audit activities. The execution system must be able to scale effectively to accommodate such surge activities. Current cloud technologies perfectly fit this requirement.

[0150] Execution will log all processing and results sets. These may be stored in many forms and across numerous targets, such as, but not limited to log files etc. All logging is immutable.

[0151] The key output is the construction and definition of entities as described in Table 4:

[0152] Table 4

[0153] According to preferred embodiments, and with reference to FIG 6, the system 100 comprises a Control Execution Object (CEO) Register 610 comprising one or a plurality of CEOs, such as CEO 1 , CEO 2, CEO 3, ... , CEO x. Control Execution Objects (CEOs) are programmatic entities that are capable of being executed. The CEOs provide significant flexibility in structuring and executing the tests to cater for many varied scenarios and usages. By example, CEOs allows for an ICT from ICT library 240 to be executed multiple times, in multiple contexts, e.g. execute a specific ICT once annually for audit evidence and every hour for monitoring purposes. Each CEO execution is performed in the context of fulfilling a given MIC and will be passed a series of parameters that guide its action.

[0154] For enterprise businesses, it is not realistic, nor may it be possible, to automate all evidencing, hence there will be an ongoing requirement for manual testing or evidence gathering. The CEO provides a ‘manual’ option which allows for consistency of definition regardless of the testing method. It will also allow the gradual introduction of automation.

[0155] A CEO will be provided the following parameters: a descriptor field to describe the purpose of the CEO; the MIC ID that the test is being ran to fulfil; a single ICT ID that describes: i) the data set(s) that are required to fulfil the evidencing needs or other process (via ICTO); ii) the definition of logical rules or algorithms that must be executed against the mapped data set(s) (via ICTO); iii) the definition of anoutput or action required based on the execution of the rule or algorithm (via ICTO). Further parameters of a CEO include: an execution start date; an execution frequency ranging from continual through to a specified period, e.g. monthly; an execution mode, for example, the CEO can be executed via a manual method or an automated / scheduled method; an output log stream; a status, which defines if the CEO status is Active (should be executed as specified) or is Suspended (not to be executed).

[0156] Each CEO, once defined, is placed into the CEO register 610, which invokes an Execution Engine EE 620 to execute the CEO at the specified time frequency.The CEO register 610 will only invoke the EE if: the CEO Execution Method = Automatic; the CEO StartDate is earlier than current date; the CEO Status = Active; and the CEO Execution Frequency period has expired.

[0157] According to preferred embodiments, the CEO principles are as follows. The CEO must be Singular in that it can execute to fulfil a single MIC and it must invoke no more than a single ICT. This will maximise reuse and reduces duplication. The CEO must be Parameterised in that it is flexible and adaptable to handle the range of prescribed parameters and their permitted values. The CEO must be Immutable because all logging is immutable.

[0158] Some CEO examples are provided in Table 5 below:

[0159] Table 5

[0160] Example 1: This example describes a MIC (MIC36) being tested by an ICT (ICT97) starting on 12 / 12 / 2021, executing weekly (168 hours), having an automated execution method and writing all output to a MIC specific log target ‘MIC_36_LF’.

[0161] Example 2: This example describes a MIC (MIC47) being tested by an ICT (ICT32) starting on 12 / 12 / 2021, executing yearly (8760 hours), having manual execution and writing all output to a MIC specific log target ‘MIC_47_LF’.

[0162] Example 3: This example describes a MIC (MIC12) being tested by an ICT (ICT6) starting on 12 / 12 / 2021, executing continually (signified by zero Ό’ in the frequency field), having an automatic execution and writing all output to a standard log target ‘STD_LF’. This example is performing a monitoring style activity.

[0163] In preferred embodiments, Execution Engines (EE) 620 are triggered by a CEO within the CEO register 610 when it is due to be executed. To ensure the system is scalable many Execution Engines can be invoked at the same time and in parallel. Execution Engines operate completely independently of all other Execution Engines. They are fully self-contained computation units with all required resources. They are able to auto-scale as required to complete the task.

[0164] The primary functions of an Execution Engine 620 are to initially verify the integrity of the CEO, then to execute and finally log all activities. The verify step is an important initial step to avoid the creation of valuable and expensive resources that are then unable to perform the required process.

[0165] The EE 620 has its own specific logging system and records execution details for each CEO. All logging is immutable. The EE 620 does not store the results set of the CEO execution, rather the results are stored within the CEO specified logging target.

[0166] Prior to executing a given CEO, the EE 620 must verify the integrity of the CEO and its component parts. Verification of the CEO and execution by the EE 620 will be described in further detail with reference to FIG 7. Starting at 710, the method of verifying the CEO includes at 720 verifying the MIC ID including determining whether the MIC ID exists in the MIC library 230 and whether the Status = ‘Active’ for the MIC ID. If Not, at 730 the method includes logging an error message and exiting the verification process. If so, at 740, the verification method includes verifying the ICT ID including determining whether the ICT ID exists in the ICT library 240 and whether the Status = ‘Active’ for the ICT ID. If not, the method includes logging an error message and exiting the verification process. If so, the method includes at 750 verifying the specified log file including determining whether the specified Log File exists and whether it is accessible. If not, at 730 the method includes logging an error message and exiting the verification process. If so, at 760, the method includes verifying all ICTOs. Verifying the ICTOs includes, for all ICTOs contained within the ICT, testing whether the ICTO CDO_Ref to verify the component is accessible. At 770, if not, at 730 the method includes logging an error message and exiting the verification process. If all ICTOs are valid, at 780, the method includes the EE 620 executing the CEO.

[0167] The Execute function at 780 will take the given ICT, and use the defined ICTO to construct the required test function. This requires technology implementation choices to be made as to how to achieve this. Traditional programming languages combined with newer cloud technologies provide many options and can be used in combination, as will be understood by the skilled addressee.

[0168] Another aspect of the present invention is concerned with the ability to provide and publish the evidence to auditors to satisfy the MICs have been met. Traditionally spreadsheets and documents have been used to provide such information, which is very manual, human intensive and time consuming. This aspect of the present invention provides programmatic interfaces to allow evidence to be requested remotely by trusted third parties when and as required.

[0169] Providing publication methods that allows third party audit firms to programmatically interrogate the system to test and validate compliance controls, within the context of a given compliance standard at any point in time, would radically change current audit working practices and allow rapid delivery of audit reports. This supports the key requirement of allowing customers to request audit reports on demand to suit their business cycles and not be constrained by the cycle dictated by the provider. For example, this is important for a SaaS provider operating globally where there will be may different business cycles to accommodate, such as varying financial years. It is also important to note that due to increasing cyber security threats, audit cycles are shortening with more focus on monitoring activities. The capabilities of the present invention described herein are supportive of such demands.

[0170] With reference to FIG 8, the Compliance Audit Interface (CAI) 820 of the system 100 provides these capabilities and returns required audit data 810 to third party auditors and their systems 830.

[0171] According to some embodiments, characteristics of the CAI 820 include one or more of the following: it utilises industry standard Web Service / API technologies for highest portability, lowest cost of implementation and to simplify adoption by 3rdparty audit firms; it is highly secure, encrypted and credentialed; credentials can be locked to one or more International standards; it can support and operate in near real time, batch mode or defined periodic modes; it is highly scalable; it logs all activities and requests and all logging is immutable.

[0172] Benefits of the CAI 820 of the system include the following: it reduces the cost, time and effort required by all involved including 3rd party audit firms and their staff to undertake the audit; it provides the ability to support multiple 3rd party auditpartners who may cover different compliance standards; it is scalable and provides the required audit data 810 in a timely manner.

[0173] A skilled addressee will determine implementation technologies and how to handle 3rdparty access and secure authentication from a broad range of commonly availably technologies, as best fits their implementation scenario.

[0174] Prior to executing a given Compliance Audit Interface (CAI) request, the CAI 820 must verify the integrity of the request. With reference to FIG 9, the CAI request verification method 910 includes at 920 verifying user credentials. If the user credentials are not valid, the method includes at 930 logging an error message and exiting the process. If the user credentials are valid, the method includes at 940 verifying the standards ID including determining whether the standards ID exists in the standards library 210 and is the Status = ‘Active’. If not, the method includes at 930 logging an error message and exiting the process. If so, the method includes at 950 verifying the MIC ID including determining whether the MIC ID exists in the MIC library 230 and is the Status = ‘Active’. If not, the method includes at 930 logging an error message and exiting the process. If so, the method further includes determining whether the MIC ID maps through to the specified standards ID. If not, the method includes at 930 logging an error message and exiting the process. If so, the method includes at 960 executing the CAI request.

[0175] Hence, embodiments of the present invention address, or at least ameliorate the aforementioned problems identified in the background and detailed description herein. Embodiments of the present invention enable audits to be performed at any point in time and real time customer audit reports to be generated which are tailored to the customers’ requirements.

[0176] Embodiments of the present invention enable the realisation of efficiency gains through the re-use of one control and piece of evidence to satisfy many standards.

[0177] Embodiments of the present invention also have the characteristic of maintainability. A smaller subset of controls needs to be maintained rather than the total superset of all international compliance standards. Embodiments of the present invention are engineered to allow underlying systems and data sources to change without radical reworking of controls.

[0178] Embodiments of the present invention also have the characteristic of scalability, i.e. ease of acquiring new standards due to the re-use of controls and the ability to more easily determine coverage and gap identification.

[0179] Embodiments of the present invention also have the characteristic of reusability. Controls and tests can be reused in multiple ways, i.e. provide audit evidence and also act as a monitoring function.

[0180] In this specification, adjectives such as first and second, and the like may be used solely to distinguish one element or action from another element or action without necessarily requiring or implying any actual such relationship or order.Where the context permits, reference to an integer or a component or step (or the like) is not to be interpreted as being limited to only one of that integer, component, or step, but rather could be one or more of that integer, component, or step etc.

[0181] In this specification, the terms “comprises”, “comprising” or similar terms are intended to mean a non-exclusive inclusion, such that an apparatus that comprises a list of elements does not include those elements solely, but may well include other elements not listed.

[0182] Throughout the specification the aim has been to describe the invention without limiting the invention to any one embodiment or specific collection of features. Persons skilled in the relevant art may realize variations from the specific embodiments that will nonetheless fall within the scope of the invention.

Claims

CLAIMS1. A method of defining one or more computer-implemented tests to demonstrate auditable compliance with one or more standards, or the like, the method comprising: compiling an electronic library of specific requirements of one or more standards or the like; translating and mapping the specific requirements to an electronic library of one or more master internal controls; and generating an electronic library of one or more internal control tests based on one or more of the master internal controls.

2. A system to define one or more computer-implemented tests to demonstrate auditable compliance with one or more standards, or the like, the system comprising: one or more processors in communication with one or more memories, one or more input devices and one or more output devices, wherein the one or more processors are specifically configured to: compile, in the one or more memories, an electronic library of specific requirements of one or more standards or the like received via the one or more input devices; translate and map the specific requirements to an electronic library of one or more master internal controls in the one or more memories; and generate, in the one or more memories, an electronic library of one or more internal control tests based on one or more of the master internal controls.

3. A computer readable medium having stored thereon computer executable code to define one or more computer-implemented tests to demonstrate auditable compliance with one or more standards, or the like, wherein the computer executable code is configured to, when executed:compile an electronic library of specific requirements of one or more standards or the like received via the one or more input devices; translate and map the specific requirements to an electronic library of one or more master internal controls; and generate an electronic library of one or more internal control tests based on one or more of the master internal controls.

4. The method of claim 1 , system of claim 2 or computer readable medium of claim 3, wherein translating the specific requirements to the one or more master internal controls comprises translating an inherent intent of the specific requirements to a context to which it will be applied.

5. The method, system or computer readable medium of any preceding claim, wherein the specific requirements of one or more standards or the like comprise criteria, controls and / or guidance to be complied with for compliance with the one or more standards or the like.

6. The method, system or computer readable medium of any preceding claim, wherein the one or more internal control tests assess the design and effectiveness of the master internal controls.

7. The method, system or computer readable medium of any preceding claim, wherein the method comprises one or more internal control test objects executing one or more of the one or more internal control tests.

8. The method, system or computer readable medium of any preceding claim, wherein the master internal controls are an abstraction layer between the specific requirements of the one or more standards or the like and the one or more internal control tests.

9. The method, system or computer readable medium of any preceding claim, wherein the master internal controls are human readable to allow display in one or more audit reports.

10. The method, system or computer readable medium of any preceding claim, wherein each master internal control addresses a single evidencable item.

11. The method, system or computer readable medium of any preceding claim, wherein the master internal controls are structured in a repeatable pattern to allow programmatic generation of the one or more internal control tests.

12. The method, system or computer readable medium of any preceding claim, wherein, the master internal controls are independent of one or more of the following relating to the one or more standards or the like: any particulars that relate to the specific requirements; a technology; a method; a person(s); time period; approach or the like.

13. The method, system or computer readable medium of any preceding claim, wherein translating the specific requirements of the one or more standards or the like to the one or more master internal controls comprises: identifying and clarifying the inherent intent of the specific requirements; deconstructing the specific requirements into singular and specific requirements; mapping the deconstructed requirements to the context to which the requirements apply; and generating an initial candidate master internal control for each mapped specific requirement.

14. The method, system or computer readable medium of claim 13, wherein, for each initial candidate master internal control, where there is an existing, identically matching master internal control, the specific requirements of the initial candidate master internal control are mapped to the existing, identically matching master internal control.

15. The method, system or computer readable medium of claim 13, wherein, for each initial candidate master internal control, where there is an existing, similar master internal control, and an intent of the existing, similar master internal control meet the intent of the initial candidate master internal control, the existing, similar master internal control is adjusted and the specific requirements of the initial candidate master internal control are mapped to the adjusted existing, similar master internal control.

16. The method, system or computer readable medium of claim 13, wherein, for each initial candidate master internal control, where there is not an existing, identically matching or similar master internal control, or the intent of the existing, identically matching or similar master internal control does not meet the intent of the existing, identically matching or similar master internal control, the initial candidate master internal control is finalised and added to the electronic library of master internal controls and the specific requirements of the initial candidate master internal control are mapped to the finalised master internal control.

17. The method, system or computer readable medium of any preceding claim, wherein each internal control test: addresses a single test; and / or defines specific logic, a date and one or more actions required to execute a single test; and / or is independent of one or more, and preferably all of the following: technology; systems; data sources; and / or.references, and declares as required, one or more internal control test object.

18. The method, system or computer readable medium of any preceding claim, wherein each internal control test object is declared with a single type which defines a form of the internal control test object.

19. The method, system or computer readable medium of any one of claims 7 to 18, further comprising a library of Compliance Data Objects (CDOs) comprising one or a plurality of CDOs to hold one or more of actual data, an expression, or point to an executable function, wherein each CDO is referenced by at least one internal control test object.

20. The method, system or computer readable medium of any preceding claim, further comprising a library of Compliance Data Adaptors (CDAs) comprising one or a plurality of CDAs to provide stored data values abstracted away from any source system or technology layer, wherein each CDA services one CDO.

21. The method, system or computer readable medium of any preceding claim, further comprising a Control Execution Object (CEO) register comprising one or a plurality of CEOs, each CEO enabling an internal control test to be executed by an Execution Engine (EE) multiple times, in multiple contexts to fulfil a given master internal control.

22. The method, system or computer readable medium of any preceding claim, further comprising a Compliance Audit Interface (CAI) in communication with the master internal control library and audit data to return required audit data to third party audit systems on demand.

Images