OSS supports the Write Once Read Many (WORM) strategy that prevents an object from being deleted or overwritten for a specified period of time. This strategy is applicable to business under the regulations of the U.S. Securities and Exchange Commission (SEC) and Financial Industry Regulatory Authority, Inc. (FINRA).

OSS provides strong compliant policies. You can configure time-based retention policies for buckets. When a retention policy is locked, you can read objects from or upload objects to buckets. However, the objects or retention policies within the retention period cannot be deleted. You can delete objects only after their retention period ends. The WORM strategy is suitable for industries such as finance, insurance, health care, and securities. OSS provides the WORM strategy to allow you to build a "compliant bucket in the cloud."

Note OSS is the only cloud service in China that has passed the audit and certification of Cohasset Associates and can meet specific requirements for electronic data storage. OSS buckets configured with retention policies can be used for business that is subject to regulations such as SEC Rule 17a-4(f), CFTC Rule 1.31(c)-(d), and FINRA Rule 4511(c). For more information, see OSS Cohasset Assessment.

Precautions

  • In OSS, you can configure retention policies only for buckets.
  • A bucket cannot have both versioning and retention policies configured at the same time. If versioning is enabled for a bucket, you cannot configure retention policies for the bucket. For more information about versioning, see Introduction to versioning.
  • During the protection period of objects in buckets, you can configure lifecycle rules to convert the storage class of the objects to minimize costs while ensuring compliance. For more information, see Manage object lifecycle.

Implementation modes

Use the OSS console. For more information, see Configure a retention policy.

Rules

You can add only one time-based retention policy. This policy has a protection period ranging from one day to 70 years.

For example, you created a bucket named examplebucket on June 1, 2013, and uploaded the file1.txt, file2.txt, and file3.txt objects to the bucket at different points in time. Then, you created a retention policy that is specified with a protection period of five years on July 1, 2014. The following table describes the dates on which these objects were uploaded and expire.
Object Upload date Expiration date
file1.txt June 1, 2013 May 31, 2018
file2.txt July 1, 2014 June 30, 2019
file3.txt September 30, 2018 September 29, 2023
  • Implementation rules

    By default, a time-based policy is in the IN_PROGRESS state after the policy is created for a bucket. The state remains valid for 24 hours. Within the validity period, the retention policy protects the resources in the bucket.

    • In the 24-hour window after the retention policy is enabled: If the retention policy is not locked, the bucket owner and authorized users can delete this policy. If the retention policy is locked, the protection period of the policy cannot be shortened and the policy cannot be deleted. The protection period can only be prolonged.
    • 24 hours after the retention policy is enabled: If the retention policy is not locked, the policy becomes invalid.
    • If you attempt to delete or modify data in the protected bucket, the OSS API operation returns 409 FileImmutable.
  • Deletion rules
    • A time-based retention policy is a metadata attribute of a bucket. When a bucket is deleted, the retention policy and ACL of the bucket are also deleted. To delete the retention policy of a bucket, the bucket must be empty. Only the bucket owner can delete the retention policy.
    • If the retention policy is not locked within 24 hours after it is created, the bucket owner and authorized users can delete the policy.
    • If a bucket contains objects that are within the protection period, you cannot delete the bucket or its retention policy.

FAQ

  • What are the advantages of a retention policy?

    A retention policy can be implemented to meet data security standards. During the protection period of a retention policy, data cannot be modified or deleted. In contrast, data protected by using RAM policies and bucket policies may be modified and deleted.

  • What scenarios are suitable for a retention policy?

    You can use a retention policy when you need to store infrequently accessed important data that are not allowed to be modified or deleted. Such data includes medical records, technical documents, and contracts. You can store these archived objects in a specified bucket and configure a retention policy for the bucket.

  • Does a retention policy apply to individual objects?

    Retention policies can be configured only on the bucket level. OSS does not support retention policies on the object level.

  • How can I delete a bucket protected by a retention policy?
    • If the bucket contains no objects, the bucket can be deleted.
    • If the bucket still contains objects, the bucket cannot be deleted even if the protection period has ended. You must delete all objects in the bucket before you can delete the bucket.
    • If the bucket contains objects that are within the protection period, the bucket cannot be deleted.
  • Will objects within the protection period of the retention policy be retained if my account has overdue OSS payments?

    Alibaba Cloud retains data for an overdue account based on the terms and conditions of your contract.

  • Can an authorized RAM user configure a retention policy?

    All API operations related to the retention policy are available. These API operations support RAM policies. RAM users authorized by using RAM policies can create or delete the retention policy by using the OSS console, APIs, or SDKs.