WORM (Write Once Read Many) storages are specifically designed for strict regulatory requirements where the data must be locked for a period of time. WORM storages have the following characteristics:
- When data is uploaded to the storage, the retention period must be defined.
- During the retention period, the data is immutable, it cannot be altered or deleted.
- During the retention period, the data can be read or downloaded at any time.
- The retention period of the data cannot be decreased, it can only be increased.
- Many vendors provide legal hold or litigation hold which can override the retention period of the data in such a way that even when the retention period expires, the data will still be locked until the legal hold is active on the data.
- Some vendors only provide WORM support on a folder/container/bucket level and not for individual data. In this case, the system cannot be integrated directly with the storage WORM features. Alternatively, the system can be configured to align the application level retention configuration with the settings on the storage. For example Immutable Blob Storage.
The system provides WORM capabilities on 2 levels:
- Application level: the system can enforce WORM specific features (data locking under the retention period, legal hold, etc.) in the application layer. While these features can ensure that the data is locked for the retention period and cannot be altered to deleted through the application, if the data is stored on non-WORM capable storage infrastructure, the data can be potentially directly accessible on the storage level and subject to modification or deletion if the user has the necessary privileges. For more information, see Data retention.
- Storage level: if the storage system supports WORM specific features, the system will also automatically use those capabilities to lock the data for the retention period or to add/remove the legal hold for selected records.
The system supports the following storage solutions with WORM capabilities:
|Storage Vendor||Storage Model||File Operations||WORM Operations||Retention Period||Increase Retention||Legal Hold|
|ECS using the Centera API/SDK||SDK||SDK||Yes||Yes||Yes|
|Unity FLR||SMB||SMB File Attributes||Yes||Yes||No|
|iTernity||iCAS||SMB||SMB File Attributes||Yes||Yes||No|
|IBM||COS||REST (AWS S3)||REST||Yes||Yes||Yes|
Many of the WORM storage platforms support a default (or minimum) retention setting on the container/bucket level. This setting is not compatible with the system and cannot be used because the system can upload additional files to the storage (e.g. transcription file, transcoded video file) in which case the retention of these files is adjusted to match the original recording. If default/minimum retention is configured, the retention of these files could be longer than required which will cause unnecessary alerts in the system, because the system will not able to delete these additional files when the retention of the recording expired.
WORM features in data management policies
Data management policies have certain features related to the WORM capabilities of the system:
|Data Management Policy||Description|
The upload policy can set the retention period for the data. When retention is set and the storage target is WORM capable, the system will automatically set the retention on the storage platform using the available methods (SDK, REST API or SMB file attribute change).
If the retention period is not set during upload and the data is uploaded to a WORM capable storage target, the data will be still uploaded but the retention period will not be set. This could cause issues if there is a minimum retention period configured on the storage system (some storage solutions can enforce a minimum retention period).
|Delete||The system does not allow deleting data under retention. The system automatically filters out the records which are under retention or legal hold. This is the case also when the filter options are matching the records in the policy configuration.|
|Increase Retention||When the increase retention policy is matching records stored on a WORM storage target, the system will automatically update the retention on the storage platform using the available methods (SDK, REST API or SMB file attribute change).|
The Copy Media policy has two modes:
- Dual Archiving: the policy creates a copy of the media files on the new storage target and links them as second copies in the database. For more information, see Resilient storage and archiving. When dual archiving is used, either or both of the storage targets can be a WORM capable storage. No restrictions apply.
- Copy and Forget: the policy creates a copy of the media files on the new storage target and rewrites the link in the database to the new storage target. The original copy is left intact. We recommend using this option when the original copy is under retention on a WORM storage and the files have to be moved to a new storage location. This means that the system will no longer manage the original copies and will not apply any policies including data retention or offer playback and download.
|Move Media||Not supported for data under retention|
|Archive in DB||The database record is moved to the archive table. It has no impact on the files stored on WORM storage.|
|Archive in DB and Move Media||Not supported for data under retention|
|Encryption, Signing||Not supported for data under retention|
|Transcription||Supported, except for data on EMC Centera under retention|
|Voice Quality Check||Supported, no restrictions apply|
|Transcode||Not supported for data under retention|
|File Verification||Supported, no restrictions apply|
|Deduplicate Recordings||Not supported for data under retention|
|Export (Advanced Export, Policy-basedExport, Policy-based Direct Export)||Supported, no restrictions apply|