Holds and preservation
To be prepared in the event of litigation, investigations, or audits, organizations must be able to prevent the destruction of pertinent records. Destruction can happen during records disposition, or it can be manually initiated by a Records Manager. By placing records on hold, the Records Administrator can ensure that they are not destroyed. When a record is placed on hold, it cannot be destroyed either through the normal disposition process or even manually until the hold is removed. In this chapter, we describe hold processing in IBM Enterprise Records.
We cover the following topics in this chapter:
8.1 Definition of hold
A hold is an action taken on records or containers to stop the disposition process that is defined in the retention policy for that record to ensure that it is available for pending actions. When the pending action is resolved, the hold can be removed from the record or container, which restarts the disposition process.
To prevent the accidental deletion of the record, a hold also prevents the record from being manually deleted, which gives the Records Administrator confidence that records that are placed on hold will be available until the pending action is resolved and the hold is removed.
Many laws and regulations govern the retention of records across a wide range of industries and geographical regions. Primary regulators in the US include the Securities and Exchange Commission (SEC), the Food and Drug Administration (FDA), the Department of Labor, and the Environmental Protection Agency (EPA). The retention regulations of these agencies must be taken into consideration when creating records retention schedules and policies, because these organizations mandate that records are preserved until a specified period of time has passed or an event occurs. After this time has passed or event happens, the records are eligible for destruction, except when the records are the subject of potential or pending litigation or investigation.
|
Note: Freeze is an alternative term for hold. The Department of Defense (DoD) specification uses the term freeze.
|
8.2 Hold processing in IBM Enterprise Records
Enterprise Records allows Records Administrators or Records Managers to identify relevant entities, such as categories, folders, volumes, or records, and manually place holds on them. Alternatively, the placing of holds can be automated through the use of conditional (dynamic) holds. By default, only users and groups assigned the role of either Records Administrator or Records Manager can create and apply holds.
Holds are automatically inherited by lower levels of the file plan. Using our case study as an example, if a hold is placed on the Operations record category, all categories, folders, volumes, and records under Operations are automatically on hold. Enterprise Records prevents anyone from overriding this hold until the hold is removed.
When a hold is placed on an entity, the hold overrides normal disposition processing.
Enterprise Records provides two disposition processes:
•Basic disposition process. A record on hold will not be added to a basic disposition report. During the report review process, if a record listed in the report should not be deleted, it can be put on hold to prevent the basic disposition process from destroying it. Alternatively, the content associated with a record can also be put on hold by using eDiscovery Manager or IBM Content Process Engine. Because the content associated with a record cannot be destroyed, the record object will not be destroyed either. When an document associated with a record is on hold by other features, such as eDiscovery Manager hold, Content Process Engine hold, or Content Process Engine retention, the disposition process does not recognize that state, and the record will be added to the report for destruction. However, the destruction of the record will eventually fail because that associated document is on hold.
•Advanced disposition process. The hold prevents an authorized user from initiating disposition on the entity until the hold is removed. All disposition actions are suspended until the hold is removed. Therefore, if a record is placed on hold after it was added to a Destroy workflow, the workflow will not delete that record. The record will be eligible for disposition when the hold is removed. Putting a hold on an entity does not prevent disposition sweep from calculating the Cutoff Date or the Current Phase Execution Date for that entity. After the hold is removed, the entity is again eligible for disposition if the Current Phase Execution Date has been surpassed.
When a hold is created, you must specify whether it is Active or Inactive (see Figure 8-1 on page 216). Only Active holds can be placed on records. A Records Administrator can define a hold at any time. However, if the hold is not to be used immediately, but later instead, or a Records Administrator determines that a hold is no longer to be used, the hold is set to Inactive.
Figure 8-1 Active and inactive holds
8.2.1 Audit and legal holds
When creating a hold, you can define whether the hold is for audit or legal purposes.
A Legal hold is used when a company must take measures to make sure that records that are the subject of pending or potential litigation or investigation are not destroyed until the litigation or investigation is over and the legal hold is lifted.
An Audit hold is used when a company must prevent the deletion of records that are the subject of internal or external auditing, attestation, or quality control processes.
Functionally, these holds are exactly the same, so Enterprise Records does not process them differently. The reason for specifying the hold type as Audit or Legal is informational only.
If required, you can alter or add to these values. The values are defined in a choice list called HoldTypeList in the FPOS. To update these values, edit the choice list using Enterprise Manager.
8.2.2 Manual holds
A hold created with no conditions is a manual hold. A manual hold is designed for dynamic use when the Records Administrator or Records Manager search or browse for records to include in the hold. The manager manually puts these records on hold. Typically, manual holds are used only for placing a small number of specific entities on hold. For instance, if you have a folder associated with a specific claim, you can manually place the folder on hold if there is an open action about that claim.
8.2.3 Dynamic holds
Dynamic holds, which are also known as conditional holds, are used to address the situation where a Records Manager needs to put a large number of records on hold and those records are potentially distributed throughout the file plan. A dynamic hold can also be run regularly to identify new documents that satisfy the hold conditions. With dynamic holds, you create search conditions to indicate which entities must be placed on hold. If there are no search conditions for a hold, that hold can be added to an entity only manually.
After the dynamic hold is created, it is applied by running the Hold Sweep application. This application searches the records repository and identifies each entity that needs to be placed on hold. It then applies the hold to each of those entities. Over time, new records can be declared that meet the hold criteria. In this case, Hold Sweep can be run on a regular schedule, and that process automatically places holds on the new records that meet the hold conditions.
The search conditions are created by using the metadata on the entity (see Figure 8-2 on page 218). The search conditions can differ for each type of entity (category, folder, volume, or record) and can use multiple pieces of metadata per item, which are joined through the logical operators AND or OR. Retrieval of the content associated with a record can be used as part of the search condition.
If search conditions are specified for multiple entity types, they are treated separately. For example, if the conditional hold is created with the following search conditions, the search does not search for records with document title that contain the words ABank and statement. Also, this condition applies to a record category that is created after 01/01/2015:
•For records with Document Title like “ABank%statement”
•For record categories with Date Created <= 01/01/2015
Instead, this search is for all records with Document Title that contain the words ABank and statement, and all record categories that are created on or before 01/01/2015.
Figure 8-2 Building search conditions for a dynamic hold
8.2.4 Multiple holds
Typically, an organization has multiple litigation actions or audits occurring at the same time, with the potential that an entity might be discovered and placed on hold for each action or audit. This can result in an entity having multiple holds on it at the same time.
For instance, suppose a company receives a letter from an opposing counsel or investigating agency about obtaining discoverable records. This action automatically triggers Hold 1 on a record (see Figure 8-3 on page 219).
In this case, we guarantee that records will not be destroyed until the end of trial process 1.
Figure 8-3 Example of multiple holds needed
What happens if another trial begins against the same record? Another hold is added to the same entity. In our example, three holds are added to the same record for three separate legal matters. Each of these holds is removed at a different time, depending on when the litigation is over. Only when the final hold is removed will the entity be eligible for disposition.
8.2.5 Applying holds
You can apply holds manually or automatically.
Placing a hold manually
By using the Browse page (Figure 8-4 on page 220), a Records Manager can navigate the file plan to identify entities to be placed on hold. Alternatively, the Search page enables the Records Manager to search for specific entities that need to be placed on hold.
To place an entity on hold manually, select the appropriate entity (or entities if you select multiple lines), right-click, and select the Place On Hold option from pop-up the menu.
|
Note: Any hold can be placed manually, even if it has a condition defined for hold sweep. When a condition hold is placed manually on an entity, it can be removed manually or by running a hold sweep for Initiate Remove Hold Request.
|
Figure 8-4 Browse page: Manually put records on hold
Placing a hold automatically
Holds can be placed on records automatically by using the Hold Sweep program. See 8.2.7, “Running Hold Sweep” on page 225, for details.
Hold icon
Whether a hold was placed manually or automatically, the hold icon is displayed next to the entity on hold, as shown in Figure 8-5 on page 221.
Figure 8-5 Icon showing that the record is on hold
8.2.6 Removing holds
Similar to placing holds on entities, you can remove holds from entities manually or automatically.
|
Note: Only holds placed manually can be manually removed. Holds placed by a hold sweep can be removed only by a hold sweep.
|
Removing holds manually
To manually remove holds, Enterprise Records offers two mechanisms:
•Browse the file plan by using the Browse page or search the held records directly by using the Search page.
To search for the held records directly, you can search for entities where the On Hold property value is equal to True.
After the appropriate record has been identified and selected, right-click and select the Remove Hold option from the pop-up menu, as shown in Figure 8-6 on page 222.
Figure 8-6 Selecting the Remove Hold option
Using this option, you are not allowed to remove a hold from multiple records at the same time.
After you select the Remove Hold option, you are asked to specify which hold you want to remove, as shown in Figure 8-7.
Figure 8-7 Selecting the hold to remove
•Use the Review Entities On Hold from the hold definition.
The most likely scenario is that the litigation or audit is complete and the associated hold must be removed from all records that are related to the specific litigation or audit. To remove this hold, use the Review Entities On Hold option that is available on the Admin page of the hold object, as shown in Figure 8-8.
a. Select the Configuration View icon in the launch bar.
b. Select Holds from the drop-down menu.
c. From the Hold list, select the hold from which you want to remove the records, and select the Review Entities On Hold option (either through right-clicking and using the pop-up menu option or using the Actions button).
Figure 8-8 Review the entities on hold
d. Search for the records that you want to remove from this hold. To list all records, leave the selection text box empty, and click Search.
Figure 8-9 Remove entities on hold from the hold object
Removing holds automatically
Holds that are placed on entities by running Hold Sweep can only be removed by running Hold Sweep again after initiating a remove hold request.
To initiate removing a hold request, follow these steps:
1. Select the Configuration View icon in the launch bar.
2. Select Holds from the drop-down menu.
3. From the Hold list, right-click the hold object from which you want to remove the on-hold entities, and select the Initiate Remove Hold option, as shown in Figure 8-10 on page 225.
Figure 8-10 Initiating the Remove Hold Request for a dynamic hold
The next time that Hold Sweep runs, all entities that have been associated with this hold will have this hold condition removed. This action includes entities that have this hold placed on them manually.
8.2.7 Running Hold Sweep
Hold Sweep is an application that is responsible for finding records that meet the conditions specified in dynamic holds and for placing holds on these records. Hold Sweep is also responsible for removing the holds when the litigation action or the audit is complete.
Hold Sweep can be run in either of two ways:
•As a command-line tool that can be launched from the operating system shell
•From the IBM Enterprise Record Task Manager
Running Hold Sweep from a command line
Before you can run Hold Sweep from a command line, you must configure it to specify which hold in which FPOS it is to run. To configure Hold Sweep, complete the following tasks:
1. From a command prompt on the machine where you installed Hold Sweep, navigate to the RecordsManagerSweep folder. Enter one of the following commands:
– For a Microsoft Windows operating system:
RecordsManagerSweep.bat -HoldSweep -configure
– For a UNIX operating system:
./RecordsManagerSweep.sh -HoldSweep -configure
This opens the Dynamic Hold Sweep Configuration Console dialog window shown in Figure 8-11.
Figure 8-11 Dynamic Holds Sweep Configuration Console
2. Specify the appropriate values for the following fields. The fields with an asterisk (*) are required (clear existing values by clicking Reset):
– CE Server Name. This is for the name or IP address of the Content Engine server.
– Port Number. This field provides the Web Services Interoperability (WSI) port number that is used by your IBM Content Engine server. For example, the default port number for Content Engine running under IBM WebSphere® Application Server is 9080, for WebLogic is 7001, and for JBoss is 8080.
– FPOS Name. This is the Globally Unique Identifier (GUID) or the name of the file plan object store in which you want to run Hold Sweep. If you do not provide a value, the Hold Sweep process runs on all of the file plan object stores that are associated with the specified Content Engine server. If the name of the object store contains extended characters, use the GUID rather than the name.
GUID is the Globally Unique Identifier of the IBM FileNet P8 domain. Every Content Engine object has a GUID, and it cannot be changed.
– User ID. This field is the user name that Hold Sweep uses to log on to Content Engine to perform calculations. The user must have object store administrative rights in the FPOS and possess Records Administrator privileges.
– Password. This field is the password for the user ID. The password must be specified each time that a change is made to the configuration.
– Hold Names/GUIDs. Name or GUID of up to five holds, separated by the (|) character. The Hold Sweep process uses only the specified holds. If no hold is provided, Hold Sweep processes all of the active holds.
– Processing Batch Size. This field is the number of entities to be processed as a batch using the Hold Sweep process. By default, this value has been set to 1000. For example, if this value is 1000 and there are 20,000 entities to be processed, Hold Sweep processes all entities in 20 batches, with 1000 entities in each batch.
– Retrieval Batch Size. This field is the number of entities to be retrieved per batch using the Hold Sweep process. By default, this value has been set to 100,000. For example, if this value is 100,000 and there are 1,000,000 entities to be processed, all the entities are retrieved in 10 batches, with 100,000 entities in each batch.
– Thread Count. This field is the number of threads to be used for hold processing. Typically, this value must match the number of processors on the server where Hold Sweep is running, but the value needs to be adjusted based on tuning the system.
– Error Log File Name. This field is the name and path of the error file to be created by the Hold Sweep process, or you can accept the default. By default, a file called HoldSweepActivity.log is created in the /FileNet/RecordsManagerSweep folder.
3. Click Configure. You will see a message indicating the successful configuration of Hold Sweep.
The execution of Hold Sweep depends on your requirements. You run it when you need to automatically add or remove holds. To avoid an impact on system performance, always run Hold Sweep when your system use is low.
To run Hold Sweep, from a command prompt on the machine where you installed Hold Sweep, navigate to the RecordsManagerSweep folder. Enter one of the following commands:
•For Windows:
RecordsManagerSweep.bat -HoldSweep
•For UNIX:
./RecordsManagerSweep.sh -HoldSweep
Verify whether Hold Sweep ran successfully by viewing the error log file created in the RecordsManagerSweep folder. If the error file is empty, the Hold Sweep process ran successfully. Otherwise, the file contains errors that you can use to troubleshoot the problem.
Depending on the number of entities that need to be processed, Hold Sweep can take a considerable amount of time to run, and it might affect normal business operations. When you need to stop Hold Sweep processing, add the -stop parameter in the command prompt:
•For Windows:
RecordsManagerSweep.bat -HoldSweep -stop
•For UNIX:
./RecordsManagerSweep.sh -HoldSweep -stop
When you are ready to run Hold Sweep again, you can execute the normal HoldSweep commands without the -stop parameter.
Running Hold Sweep from Enterprise Content Manager
Enterprise Records now allows users to run Hold Sweep from the IBM Enterprise Content Manager Task Manager. This is a convenient alternative to running the tool from the command line.
Because Enterprise Content Manager calls the tool directly, it is necessary to install and configure the Hold Sweep tool in each instance of Task Manager.
Task Manager requires the Hold Sweep tool to use the EJB transport protocol (by default, hold sweep uses WSI). To set the Hold Sweep tool for EJB, complete the following steps:
1. Navigate to the RecordsManagerSweep folder, and edit the RecordsManagerSweep.bat file (or RecordsManagerSweep.sh for UNIX).
a. Update the following line:
Set CONNECTION_TYPE=WSI to CONNECTION_TYPE=EJB
b. Update the APP_SERVER variable:
Set APP_SERVER=WebSphere to the correct application server.
c. Go to the section that corresponds to your application server in the command file, and follow the instructions provided in the command file for that application server.
2. Because Task Manager provides all of the required parameters at run time, configuring Hold Sweep is not required. However, we suggest that you test the validity of all of the changes made to the command file by following the configuration instructions in “Running Hold Sweep from a command line” on page 226.
For more information, see “Configuring sweeps” in the Enterprise Records topic in IBM Knowledge Center:
3. After Hold Sweep is configured, you can launch the tool from Task Manager with the Enterprise Records web application. Click the Task View icon from the launch bar, and select Schedule Hold Sweep in the Schedule drop-down menu, as show in Figure 8-12.
Figure 8-12 Schedule Hold Sweep
4. Provide the necessary information, as shown in Figure 8-13 on page 230:
– File plan repository. File plan repository that Hold Sweep is to scan.
– Logs output directory. When Hold Sweep runs, it generates an activity log. That log is automatically uploaded in a Content Process Engine repository and provided to the user for review. These parameters define the location in Content Process Engine where the log will be stored.
– Holds. Select one or more holds.
Figure 8-13 Set parameters for a Hold Sweep task
5. Click Next to provide schedule information, as shown in Figure 8-14. Provide the name of the task. If you want to run that tasks regularly, select Run on schedule and provide the repeat information.
Provide the user name and password that the Hold Sweep will use to search for the records to be held. This user must be able to update the properties of all the records that will be found.
Figure 8-14 Configure a Hold Sweep schedule
6. Click Schedule Sweep to complete initiating the task.
8.2.8 Inheritance of holds
A hold can be placed directly on a record, or it can be set at a point in the file plan. If it is set on an individual record, only the record on which the hold is placed is on hold. If it is set at a point in the file plan (such as a category or a folder), all records and containers filed below that point in the file plan hierarchy inherit the hold.
8.2.9 Disposal trigger aggregation level effect on holds in advanced dispositions
A factor that influences hold functions is the aggregation level of the disposition schedule’s internal trigger that applies to the entity. If a record is put on hold but the disposition of the record is aggregated at a higher level (folder or category), the hold on this record prevents the entire folder or category from disposition. The problem is that an organization might have more records on hold than they are really aware of, resulting in records that they thought were eligible for disposition but not being processed. To avoid this behavior, you have two options:
•Evaluate the impact of aggregation at the record level. This is not recommended because of the performance impact of this type of aggregation.
•Check Destroy containees not on hold, which is available on a Destroy or Auto Destroy type of action. When this option is selected, the destroy workflow or the automatic destoy sweep destroys any records that are not filed as On Hold in the container. The container itself will not be disposed of, because it still contains the records that were put on hold.
8.3 Performance considerations
From a database perspective, Hold Sweep is a resource-intensive operation. For this reason, it is best to schedule Hold Sweep to run when system use is low. To set the correct expectation, if you have a conditional hold that might put approximately a million records on hold, Hold Sweep can take several hours to complete.
The Hold Sweep configuration has a processing batch size (set to 1,000) and a retrieval batch size (set to 100,000). These values have been sized for production use. Change them only after you thoroughly examine and understand the implications of changing them.
For instance, the 100,000 batch size for retrievals means that the Java virtual machine (JVM) that is running Hold Sweep needs at least 1 GB of heap memory to be able to process the result set, and the QueryPageMaxSize setting in the Server Cache Configuration of IBM FileNet Enterprise Manager is set at a value greater than this batch size.
Increasing the thread can increase the throughput of the hold process at the expense of an increased processor load. Perform tuning to determine the optimum thread count for your environment; however, never set the thread count higher than the number of processors on the server where the hold is running.
Unlike disposition sweep, the size and depth of a file plan have no affect on the performance of Hold Sweep. Hold Sweep uses the conditions defined in the hold definition to directly search for entities no matter where they reside in the file plan. Therefore, it is important to ensure that these searches run optimally, which means that the best practice is to routinely tune the underlying database.
Create database indexes for the metadata elements that are expected to be searched frequently. In addition, create the database indexes on two system properties that are defined on entities: On Hold and Prevent RM Entity Deletion.
The searches are also ordered by GUIDs. Therefore, it is critical for large systems to build a cluster index on GUID to improve performance.
The more complex the condition, for example, with multiple attributes or content-based retrieval, the greater the impact on hold performance and the longer that it takes to run the hold.
If a hold contains conditions for separation, such as records, folders, and categories, there are three independent searches, which Hold Sweep performs sequentially. For example: A hold is being created for a litigation action that is underway against a contractor to Fictional Insurance Company XYZ. This contractor has both contracts and claim documents that need to be put on hold, so conditions have been created to search for both records and folders that have the contractor’s ID in the respective VendorID or CustomerID metadata fields.
When Hold Sweep is run, it treats the two search conditions as independent searches and runs and acts on them sequentially. In this example, it first searches for and places on holds all records where XYZVendorID=A123456, and it then searches for and places on holds all folders where XYZCustomerID=A123456.
Finally, as a general rule, it takes Hold Sweep the same amount of time to remove holds from entities as it takes to put the entities on hold initially.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.