Case Management Systems

This is an Insight article, written by a selected partner as part of GIR's co-published content. Read more on Insight

Introduction

This chapter sets out how to design and build an effective Case Management System (CMS), to support the activities of an in-house investigations team and their organisation.

A CMS can enable improved reporting, triaging and investigative capabilities ensuring that the investigation teams are compliant both with internal policies and external regulatory requirements.

How to build an effective CMS for an organisation

The introduction of a powerful CMS can be the key to a very successful in-house investigations team. Several elements must be considered before starting the project. This list below whilst not comprehensive can provide guidance to some of the most relevant stages.

Sponsorship

As for all corporate projects, the implementation of a case management system must obtain the right level of senior sponsorship inside the organisation to be successful, ideally at executive committee level. Alternatively, the system can be presented to the audit and risk committee as the effective instrument to provide essential information related to key governance processes of the company, an example being compliance and anti-fraud processes. Users from different departments can be identified as stakeholders within the organisation to guarantee an inclusive development of the case management system. Another effective approach to successfully introduce the capabilities of the system is referencing global policies of the company and the ability to manage compliance matters.

Multi-department users’ base

From this perspective, the CMS can support multiple processes that are normally owned by different departments, such as audit, legal, compliance, security, and Human Resources (HR). These teams can see the benefit of gaining access to and use of an automated solution and their participation can have a strategic positive effect on the successful implementation of the system; for example, budget requirements can be split among different departments, database can grow and become a source of intelligence for several organisational functions.

While a preferred initial approach would be to limit the use of the system to some clearly identified and specialised users or functions, in a more mature scenario the access and the use of the system can also be considered for customers facing functions, e.g. retail staff. This approach can make incident reporting and analysis processes very effective and also provides a complete information database to the investigators.

Users access management

Users access management principles must be strongly embedded in the build of the system. The owner of the solution must retain control and issue access credentials to trusted users only. As the case management system is essentially an IT product, the criteria of confidentiality, integrity and availability of the information are paramount for a successful implementation and in-life cycle of the system, and for the security of the organisation.

Users’ and groups logical segregation

Due to the confidential nature of the information stored in the case management system, a logical segregation of the users is also essential. Access to cases can be organised by the creation of specific groups, i.e. all the users that belong to a specific group or team will all have access to the same cases. Access can be further partitioned to varying levels of management oversight within the same group or team. Access to extremely confidential cases can be limited only to individuals with advanced access level, senior investigators and managers. The combination of the two segregation criteria will allow a lot of flexibility in managing access and visibility to cases inside the organisation to guarantee the expected level of confidentiality.

Security assessment

Once the best IT solution has been identified it is strongly advised that the system’s architecture and its technical elements are assessed by the cyber security team to confirm the system is fully aligned with the cyber security standards of the organisation. This will mitigate any risk of uncontrolled access, or potential external or internal security breaches, to the confidential information stored in the system and loss of critical data.

Privacy requirements

While building an effective system to store information and manage investigations effectively, some relevant compliance requirements must be considered from the beginning. Many investigations involve accessing and using Personally Identifiable Information (PII). A ‘privacy security assessment’ is therefore necessary before the implementation of the system. This approach will confirm compliance to regulatory requirements, e.g. privacy legislation, and mitigate risks. In this respect data retention principles must also be considered when building the case management system. Automated technical solutions, e.g. deletion scripts, can help to adhere to data retention principles and reduce the manual intervention of the system owner and users to delete the data that cannot be retained any longer.

Audit features

Audit features are essential to control the correct use of the system. They can help the owner to verify that data have not been compromised as well as identify the root causes of potential issues in the system. From another perspective, these features can also provide to external parties, e.g. external auditors or other authorities, the confidence that data stored in the system is genuine and not compromised and evidence the integrity of one case history and management actions executed by the users.

Internal processes and compliance requirements

An effective CMS can be structured to make compliance to policies and internal processes more effective. Specific notifications and workflows can be built to help the investigation teams to notify other stakeholders while managing incidents. For example, incidents involving potential data breaches, automatic notification can be sent to the data privacy officer, the same could apply for potential compliance breaches like gifts and entertainment. For other specific categories of incidents, special fields can be made mandatory to guarantee that the key information required by process are included in the case record during the initial creation of the incident record.

The CMS can be specifically designed to support the company internal whistleblower program. The system can be configured to automate feedbacks and update to whistleblowers to acknowledge receipt of the concern and at specific intervals regarding the status of the investigation, as well as notifying internal stakeholders when a specific category of incidents has been reported, such as high-impact frauds or specific types of grievances. Automated workflows can be designed to send notification emails, and this can be a great advantage when volumes of reports or availability of resources pose a threat to handling incidents in a timely manner, in line with policies and internal standards. Additionally, the system should be equipped with automating managing information features for the analysis of trends and statistics, for example; volumes and frequency of the incidents. These elements can be beneficial to assess the effectiveness of the whistleblower programme inside the organisation, for example across countries, departments, or in certain periods of the year, and provide support to other key functions business, HR, and compliance.

Best fit for the business

The in-house investigation team can have the opportunity to lead the project of implementing a new case management system in their company, or to support another leading function. Probably the first consideration to be made is if the company can satisfy its requirements with some ‘off-the-shelf’ solutions available on the market or, instead, develop a completely customised in-house system. There are numerous points that should be considered while preparing this assessment, examples of which are:

  • Budget: costs of programs can vary widely;
  • Time: FTE time commitment to develop a customised solution;
  • Complexity of the organisation: requirements from all business entities;
  • User’s base: Investigations and security or include audit and
  • compliance for example;
  • Cyber security requirements: does housing of the data meet the regulatory requirements;
  • Integration with other existing in-house systems, e.g. HR, IT office solutions, data analytics or third party systems via application programming interface; and
  • Compliance e.g. data privacy requirements.

If the decision is to opt for an existing ‘off-the-shelf’ product, some operational challenges must be considered. CMS’s may be too simple or too complex for the specific needs of one organisation and designed essentially for incident management or program management, as well as being designed for processes different from investigations management.

This can pose limitations to the usability by the investigations team. Investigation cases could require some sophisticated features which could be better provided via an ad-hoc customisation. Therefore, it is recommended to check with the developer if specific requests can be accommodated. Same applies to solutions developed internally, where alignment with the IT department must be completed at the early stages of the project.

In both cases, the developer’s team will have to provide clarity on the maintenance requirements and support services provided in the short and long term for the lifecycle of the product.

How to build effective investigative records with a case management system

Each company or organisation is unique in its requirements about what, when and how data should be captured within a case management system.

What a case management system should capture

What the CMS should capture or contain is driven by both Internal and External requirements and is dependent on the nature of the organisation’s business; e.g. banking, oil and gas, or telecommunications would most likely have different drivers while building their solution.

The following basic elements should always be considered.

Unique incident reference number (UIRN)

The structure of a UIRN, can be defined in various ways. Generally, UIRN’s can consist of year, month, and a sequential number. The sequential number can be based on a monthly, yearly, or continuous numbering system:

  • 2020-10-001
  • 2020-10-002

UIRN’s can also be structured to reflect industry specific requirements or other case management goals: for example, they can be used in a format that can uniquely link to a customer file.

Start and end date of incident

The date the incident occurred on. This date field can also be an indicator of over what period an incident occurred if both ‘from’ and ‘to’ date fields are available. Hours and minutes can also be relevant in specific circumstances.

Incident report date

This would represent the date on which the incident was reported to the incident manager or logged in the CMS. It can be useful to have this field as separate and additional to the previous one.

Incident classification

Incidents can come from a wide variety of areas; bribery, tax evasion, misappropriation, blackmail, nepotism, etc. Due to the wide range of incident classifications available and the need for reporting in a consistent manner to internal stakeholders or externally, it is advisable to cluster incident classifications into tiered groupings. Several options can be made available to the person in charge to log the incident to guarantee the correct level of preciseness. At a higher level, categories of incidents should be aggregated under clusters. Refer to Chapter 3, corporate investigations typology, for examples of clustering.

Further clustering can be based on the position of the individual or individuals involved in the incident under investigation, which can be either ‘internal’ or ‘external’ to the organisation. ‘internal’ can refer to an employee or a contractor of the organisation; ‘external’ can be any third party with no relations to the organisation.

Sub-categories should also be considered when building this field, as the need for more in-depth reporting arises. A good example of this could pertain to conflicts of interest. Conflicts of interest incidents can be further classified into more specific types like nepotism, undeclared close personal relationships, undeclared relationships with vendors and third-party partners and using company equipment or property for private purposes. This will allow a more granular analysis of trends to adopt more specific countermeasures.

This architecture of clusters, main categories and sub-categories of incidents must be well designed before the project is initiated as changes requested later could be difficult to manage by the developer. Additionally, the main stakeholders for the project must be consulted beforehand to agree on the list of options that will be implemented, because any future changes or additions could compromise the reliability and usability of statistics and comparison of historic data.

Incident location

Data related to the location of incidents are valuable and can provide insight into trends as the CMS database and usage matures over time. This can also drive improvement opportunities in both the organisation’s control environment and the awareness activities.

Location data can be recorded as physical addresses, building name or include Geo locations. Geo tagging records option in a CMS is particularly useful for businesses operating in rural areas and will allow incidents tracking even if there are no physical address details available.

Business units

Each organisation is unique in its business unit structures. Incidents should be related not only to a physical location but also to one organisational structure and this is to be reflected in the CMS business units’ fields. There are several examples of business units with sub functions and below there are a few examples that can be considered while designing the CMS incident forms structure:

  • Procurement team
  • Technology department
  • Compliance teams per regional location
  • Research and evelopment unit
  • Warehouse ABC
  • Plant XYZ
  • Unit or Branch 123
  • Store town-name
  • Productive site alpha
  • The CMS should reflect these structures and be updated as company restructuring and reorganisation activities happen.

Reporting people and assets

Include people and assets such as witnesses, reporters, persons of interest, and items. To ensure that the details of the individuals involved in an incident are captured correctly and are aligned with the information stored in the HR systems, integration between the CMS and the HR database can give strategic value. The integration can facilitate the initial work of the investigators in confirming some basic information related to the case.

This standard data transfer between the CMS and HR systems will also allow, as the CMS matures, an effective linkage of incidents to individuals mentioned in various reports over time. How individuals are associated with an incident is important and the CMS must give several options to classify the correct level of association with an incident. For example, individuals can be recorded and classified as:

  • Reporter
  • Witness
  • Subjects of interest
  • Victim

Description of the incident

In addition to the incident classification, the incident log should have a dedicated field for a brief description of the incident. This can be a free text field and allow the case manager to include what happened, when the incident happened and who was involved in a narrative form that facilitates the understanding of the case, sometimes for the benefit of people not directly involved with the case management; for example, audit, or senior management or time after the incidents have taken place. This will allow any other interested stakeholders to obtain a brief view of the incident without being required to review lengthy original documents. Potentially including the following:

  • Who?
  • What?
  • Where?
  • When?
  • How?
  • Why?

Attachments

An attachments section is the area where the original complaint, any correspondence related to the incident, evidence documentation as well as the final investigation report are uploaded and stored.

The Attachments section can also be utilised to store evidence packs for any subsequent legal necessity. Privacy, legal and cyber security requirements must be carefully assessed when using attachments and storage options within the CMS.

Investigation diary

Investigators know how important it is to record the details of how the incident was managed. It is also important to keep a clear timeline of the investigation process and the steps taken during the investigation. An investigation diary area should be created in the Investigation record and reflects at minimum dates, authors and details of actions taken. All steps should also be recorded in sequential order, like:

  • 1/10/2020 Author: John Snow.
  • Interview of “XY” in ‘place.” See attachment 1.
  • 2/10/2020 – Author: John Snow.
  • Laptop number 12345 was recovered and sent to CERT. See attachment 2.
  • Investigation diaries are especially valuable in case of future lawsuits or employee tribunal scenarios.

Investigation or case owner

Once a new investigation is logged it must be assigned to an owner. The CMS must clearly include a field that shows the investigation or case owner. This will allow the organisation to track the actions, the performance and it also triggers a positive sense of ownership in the investigation team. Normally incidents have more than one person taking part in the investigation process and role descriptions can be added to the CMS to clearly define the role of each individual. Examples of these are:

  • Lead investigator
  • Supporting Investigator
  • Legal representative

Investigation status

An investigation record in the CMS must clearly show its status, which can either be ‘open’ or ‘closed’. The default status of a newly created incident should always be by default ‘open’ until the full resolution of the case. This field will be strategic for statistics and reporting purposes and to keep the performance of the team under control. Any additional status options, like on hold, pending etc. could be misleading and should be avoided.

Investigation outcome

Another strategic field that must be included in the investigation record is outcome of the investigation. Once the case owner is ready to close an incident, the outcome of the investigation must be recorded in a clear and unambiguous way. There follows possible options to be included in the CMS.

  • Substantiated: the allegations raised were found to be accurate and true.
  • Not substantiated: the allegations raised were found to be inaccurate or untrue.
  • Closed due to the lack of actionable information: the original report only provides high-level allegations and no details that would allow a start of an investigation.
  • Partially substantiated: elements of the original allegations have been found to be accurate and true, but others have not been confirmed. This option can be tricky to use for reporting and statistics since the conclusions do not appear to be straightforward so, in case it’s implemented, investigators must carefully manage the expectations of their stakeholders.

Consequences

Consequences management can fall predominantly in the remit of other functions than the Investigation team, and normally occurs after the investigation process has been completed. Nevertheless, keeping records of the consequences of an internal investigation is a strong element to prove the efficiency of the investigative process, so the incident log in CMS should include fields to record them. Below are few examples of consequences values that can be set in the system:

  • Warning to employee or employees
  • Dismissal of employee or employees
  • Report to police

Capturing the consequences of the investigation within the CMS should be based on internal policy guidelines, employee law, and privacy considerations.

Investigation lifecycle

An investigation record can be organised in different lifecycle phases to facilitate the monitoring of the process and guarantee compliance. The CMS can be built to display these steps in the interface. Lifecycle elements should be derived from company processes and policies.

  • New incident: creation of the record in the system inputting the minimum and mandatory set of information that triggered the process.
  • Assessment: initiating the triage process by sharing the record with key stakeholders in charge to decide on the kick-off of the investigation and associated methodology.
  • Investigation: execution of investigative activities by the case owner.
  • Findings: inputting key information in the system, e.g. documents and sharing outcome with stakeholders.
  • Closure: recording final comments and decisions and complete the case record.

Other internal requirements

The above list of the basic data fields for the management of the investigative records can be optionally expanded further by considering other internal drivers, which are defined by each organisation to fit perfectly with their specific requirements. Company policies that can underpin the use of the CMS would encourage the organisation’s user base to utilise the system and input the required data as a matter of policy compliance.

Specific policies can drive an extensive usage of the internal CMS, making clear reference to when and how incidents should be reported for investigation.

  • An anti-fraud policy usually defines what is considered as high impact fraud cases, what details should be reported and whom should be notified.
  • An HR policy that sets the tone in respect of a code of conduct requirements and whistleblowing processes.

Internal investigation standards or policies.

Investigations resulting from internal controls detections, or from controls gaps, can also influence the type of data and fields requirements within the CMS. Examples of these are fraud management systems (FMS), data loss prevention (DLP) systems, travel and expenses control systems, procurement systems, sales management systems and payroll systems. Furthermore, internal reporting needs within any organisation are a key driver of a CMS configuration and what values or information should be captured. Examples of these can be the following:

  • Audit requirements– both internal and external
  • Risk Management functions
  • Compliance requirements
  • Legal
  • HR
  • Investigation teams’ KPIs

The CMS can greatly improve reporting speed and accuracy. This subsequently will result in high-quality data driven reports which improve transparency of the investigative activities to the key stakeholders.

External requirements

Other fields can be included to meet the reporting requirements of general legislation or specific sector regulations, for example:

  • EU General Data Protection Regulation (GDPR).[1]
  • Whistleblowing directive.[2]
  • Jurisdictional directives, EU Modern Slavery Act 2015.[3]
  • The Foreign Corrupt Practices Act of 1977.[4]
  • UK Bribery Act 2010.[5]
  • Or other public controlling bodies, i.e., US Department of Justice (DOJ), Financial Conduct Authority (FCA), Office of Communications (Ofcom) and Information Commissioner’s Office (ICO).

Additional options

In addition to all what has been listed so far, the following fields can also be considered to create a very robust investigative process and complete database

Intake method or origin of whistleblowing reports

There can be several methods by which an individual can report concerns. These options can be embedded in the system, for example:

  • Whistleblower hotline reports
  • Media news
  • Emails or letters

Value lost and value recovered

Fraud type incidents normally involve a loss, in certain cases a protection of persons who report breaches of union law, total or a partial recovery of the initial loss. The record keeping of fraud losses and any recoveries made are a key metric for the fraud management processes of the organisation, as well as for other types of incidents investigated, e.g. vandalism.

Anonymous versus named reports

Whistleblower reports can be either anonymous or named. The measurement of the anonymity rate of reported incident is considered a good indicator of trust in an internal whistleblower program.

Reviewer triage commentaries

The assessment triage of an investigation, once it is newly received and once it has reached the closure stage, is worth being kept recorded among the other investigative records, for example to ensure that there is:

  • Alignment on the understanding of the content of any new report.
  • Agreement on suggested investigative steps and implications.
  • Agreement on who need to know.
  • Agreement on findings and associated outcomes of an investigation.
  • Agreement on suggested recommendations and improvement opportunities post the investigation.

Capturing triage comments both on the initial phase and on the closure phase can be an important element in displaying the robust nature of the end-to-end investigative process.

Recommendations and improvement opportunities

Post any investigation recommendations and improvement opportunities would result from the investigative process. The recording of these and the assignment of ownership to ensure that recommendations and improvement opportunities are actioned and completed should be logged within the CMS.

Audit logs related to accessibility of investigative records

All CMS solutions should embed auditability of their usage. This includes a system level, incident level and user level audit capability.

  • System level audit: What changes have been made to the system, including date, time, and user details?
  • Incident level audit: What changes has been made to a specific incident, including date, time, user details and field values updated?
  • User level audit: What actions did a specific user perform over time?

How to manage the investigative records

Once investigative records are created consistently in the organisation, an effective CMS not only should allow a precise recording of all the key information related to a case, but also must support the investigation teams throughout all the key phases of the investigation lifecycle. The saying goes ‘the information in any system is as good as the person sitting behind the keyboard’. This comment is also valid for a CMS. However, the quality of the data in a CMS can also be improved by defining a digital investigation lifecycle and some key data entry points to ensure accurate records management in the various stages of the investigation lifecycle. As said before, this investigation lifecycle can be unique for each organisation and defined by internal policies and the organisation’s reporting needs.

Investigation lifecycle

A structured investigation lifecycle and its data checkpoints can be designed as follows.

New incident creation

Key fields to complete before moving to the next stage:

  • Date and time reported
  • Date and time of incident
  • Incident type classification
  • Report origin
  • Initial complaint or report attached
  • Business unit or market impacted

Assessment or triage

Key fields to complete before moving to the next stage:

  • Brief description
  • Incident severity categorisation
  • Assessment or triage by the appointed stakeholders
  • Key employees and functions involved

Investigation

Key fields to complete before moving to the next stage:

  • Case owner or investigation leader
  • Loss and recovery values
  • Links to previous incidents
  • Incident diaries

Findings

Key fields to complete before moving to the next stage:

  • Outcome
  • Consequences applied
  • Final investigation report
  • Confirmation of incident classification and that the appropriate outcome is logged against each specific breach; note that one single report can contain various allegations of which the outcome can differ from allegation to allegation.
  • Attached evidence packs and any other correspondence relevant to the investigation.

Closure

Key fields to complete before final closure:

  • Closure assessment, Triage, and closure comments.
  • Investigation status update, open to closed, and date of closure.
  • Notification of closure to stakeholders.
  • Logging of recommendations and improvement opportunities.
  • Feedback to the reporters

Providing feedback to reporters instils trust in the investigation process. When feedback is provided, timing of the feedback and the level of details included in the feedback should be considered. In terms of CMS architecture, feedback to reporters can be automated via workflows, e.g. via emails, and logged in the system.

The established frequency for the feedbacks can be linked to the investigation lifecycle previously discussed and automated within the CMS to trigger communications as the investigation progresses through the various stages. Below are a few examples of timing and automated feedback responses:

  • when a new report is received and logged for the first time in the CMS;
  • when a report or investigation reaches a certain age with an open status, e.g. 30 days and then at recurring intervals; and
  • when the investigation is finalised and an outcome has been decided, substantiated or not substantiated.

This automated method of feedback is dependent on the availability of the reporter contact details and how this information is stored within the CMS. The level of details provided to a whistleblower or reporter should be governed by organisational policies, privacy, and legal considerations.

Visual analysis

CMS solutions build a rich database over time that can be useful for other internal investigations, or to steer security activities, such as security awareness programmes, and to improve the governance of the organisation. CMS data can also be a source of intelligence for trends and behaviours. The ability of a CMS to link incidents and various data points across different investigations that occurred at different points in time is a strategic element that can be considered to include visual analytical features in the system. The usability of this intelligence is dependent on what capability the CMS must visually present the data in a clear and understandable format. Examples of values or items to be linked are:

  • Involved people and functions or teams.
  • Reports originating from a specific business unit.
  • Similar type incidents, by category that re-occur over time or in specific locations.

When designing CMS visual analytical capability, also data retention principles should be cross checked so as not to risk losing key information that would make the link analysis ineffective.

AI and workflows

The inclusion of AI and automated workflows within the CMS structure will bring efficiency to reporting, stronger compliance as well as improve response time to high impact security incidents. If one policy describes a specific type of event as of high impact for the organisation, fraud equal to or above a certain loss value, an automated workflow can be utilised to inform the required stakeholders without user intervention when such an incident is logged in the CMS.

AI linguistic and analytical capabilities can allow ingest of a new reported incident in the CMS whereby the AI will auto-categorise and classify the incident prior to any user intervention. This will then trigger the required workflow notification process, improving response and notification time and ensure compliance.

Comprehensive searching

As mentioned before, an effective CMS builds a vast and comprehensive database of incidents and investigative information. Dependent on the organisation data retention rules, the database can be a relevant source of information years after investigations have been closed, for example for litigation purposes or employee tribunals cases.

The search and indexing capability of the CMS is an important technical element to discuss with the developer since the very beginning of the project. This will allow quick identification of specific incidents and retrieve details years after the matter was concluded. The design of such features must always consider data retention principles and work around the information that will be subject to deletion, like PII.

How to add value to one organisation’s governance using an effective CMS

Building policy controls in the CMS

Each organisation relies on several internal policies to govern the key processes and strategic elements of compliance. An effective CMS can add a wealth of value to one organisation if it is designed and it operates in support of the various reporting and compliance requirements. For example, if the internal audit department needs to be notified of specific incidents, building a customised workflow in the system can help the whole organisation to adhere to this requirement and not leave any communication gaps.

Another example can be related to GDPR compliance: when a new incident is logged in the system and certain elements of data breach are included, a workflow can inform a dedicated individual in charge for managing the process or one office in the privacy department, so they have access to strategic information in real time, rather than relying on off-line reporting or emails.

Finally, the system can be designed to automatically extract data and assemble reports for internal stakeholders. For example, the finance department can receive regular reports of frauds or lost assets.

Data analysis

The amount of information stored in a case management system can provide additional benefits through an efficient analysis of the data collected. Equipping the case management system with strong analytical features can be a strategic decision that can help generate trend analysis, manage KPIs and prepare predictive models to prevent incidents from re-occurring.

Additionally, a punctual data analysis of cases, losses, geographical distribution, frequency, will provide senior decision makers with evidence to support specific projects or budget requests, such as an increase in resources.

An alternative to installing data analysis features directly in the case management system, the tool can be integrated with external powerful software of data mapping and analysis to provide the expected level of insight to the organisation.

Risk management

Risk management has become an essential governance process for all organisations. Investigators are familiar with the concept of issuing recommendations and reviewing lessons learnt resulting from a case. As best practice, the risks identified during the investigation should be shared with the process owners and with the functions in charge of risk management in the organisation. A CMS which has been strategically built can add value also in the management of such process.

The investigators can consider embedding, within their CMS, a risk matrix that reflects the one in use in their organisation. With this approach the key risk indicators can be updated with the result of the investigations, for example reflecting the frequency of specific incidents as well as their impact. If the company is already using a dedicated risk management system, an API with the case management system will be a smarter solution to establish and automate flow of key information between the two. The added value of investigations and their outcomes can reverberate directly on all the governance processes and improve the overall performance in respect of risk management and risk

Quality assurance

In general, there are two approaches to Quality assurance (QA) with reference to CMS:

Independent QA teams or functions that will, at agreed intervals, audit CMS records and compare them to a set of define controls. QA findings will either be directly communicated to the business owners and or system owners. The owners will in turn agree on CMS mitigation and or improvement plans and implement accordingly.

A well planned, designed and built CMS will have the capability to accommodate QA elements. QA elements can be derived from policies or investigation process, as explained previously in the investigation lifecycle section.


Footnotes

[1] General Data Protection Regulation (GDPR) Compliance Guidelines. (2022). https://gdpr.eu/.

[2] Directive (EU) 2019/1937 of the European Parliament and of the Council of 23 October 2019 on the 305 OJ L (2019). http://data.europa.eu/eli/dir/2019/1937/oj/eng.

[4] Spotlight on Foreign Corrupt Practices Act. U.S. Securities and Exchange Commission. Retrieved June 25, 2022, from https://www.sec.gov/spotlight/foreign-corrupt-practices-act.shtml.

Unlock unlimited access to all Global Investigations Review content