(DOCSP-45917) Revises per explicit edits from v1 review. (#55)

* (DOCSP-45917) Revises per explicit edits from v1 review.

* Revises per copy review.

Author: erabil-mdb

source/compliance.txt

@@ -47,9 +47,9 @@ those specific to highly-regulated industries.
 several other certifications. The full list of certifications is included
 in this section.
 
-These certifications serve as a foundation for meeting industry-specific
-regulatory requirements. Use these certifications to maintain security controls
-and ensure that your data practices align with necessary compliance demands.
+These certifications mean you can configure {+service+} to comply with a 
+particular standard. Be sure to follow the recommended settings for the 
+standard to ensure compliance.
 
 {+service+} maintains the following certifications:
 
@@ -74,14 +74,18 @@ Encryption
 ~~~~~~~~~~
 
 You can implement encryption to ensure data security and compliance across all
-stages of data handling.
+stages of data handling. Encryption is one of the most common requirements for 
+ensuring compliance with certain standards and {+service+} offers a robust set 
+of encryption options to satisfy the requirements.
 
 - By default, |service| encrypts data in transit. To ensure data privacy and
   regulatory compliance, |service| requires |tls-ssl| to encrypt the connections
   to your databases. In addition, you can configure SSL or TLS OCSP certificate
-  revocation checking. To learn more, see :atlas:`OCSP Certificate Revocation Check <oscp-cert-check>`.
+  revocation checking. To learn more, see `OCSP Certificate Revocation Check <https://www.mongodb.com/docs/atlas/setup-cluster-security/#std-label-oscp-cert-check>`__.
 
-- By default, |service| encrypts all data at rest. |service| uses |AES-256|
+- By default, |service| encrypts all data at rest using 
+  `cloud provider disk encryption <https://www.mongodb.com/docs/atlas/security-kms-encryption/>`__. 
+  |service| uses |AES-256|
   encryption to encrypt all data stored in |s3| buckets in your |service|
   {+database-deployments+}.
   In addition, |service| supports using |aws| |kms|, |akv|, and |gcp| to
@@ -90,7 +94,8 @@ stages of data handling.
   <security-kms-encryption>`. 
 
 - You can use :manual:`queryable encryption </core/queryable-encryption/>`
-  to secure queries on encrypted data. With queryable encryption, sensitive
+  to secure queries on encrypted data on select, sensitive fields 
+  in a document stored on MongoDB. With queryable encryption, sensitive
   information remains protected even when users run queries on data.
 
   Use  well-researched non-deterministic encryption schemes to maintain
@@ -100,14 +105,15 @@ stages of data handling.
 
   - Encrypt sensitive data fields from the client-side.
   - Store sensitive data fields as fully randomized encrypted data on the database 
-    server-side.
+    {+cluster+}-side, run with {+service+}.
   - Run expressive queries on the encrypted data. Choose encryption configurations
     that support expressive queries on the encrypted data.
 
   MongoDB completes these tasks without the server having knowledge of the data
   it's processing.
 
-  Sensitive data is encrypted throughout its lifecycle, in-transit, at-rest, in-use,
+  When using queryable encryption, sensitive data is encrypted throughout its 
+  lifecycle: in transit, at rest, in use,
   in logs, and backups. The data is only ever decrypted on the client-side,
   since only you have access to the encryption keys.
 
@@ -126,8 +132,13 @@ stages of data handling.
 Data Sovereignty
 ~~~~~~~~~~~~~~~~
 
-{+service+} simplifies data sovereignty compliance through global {+clusters+}
-with zoned sharding.
+{+service+} supports over 110+ regions across |aws|, |azure|, and |gcp|. 
+This global distribution of supported locations ensures that you can 
+provision clusters and store data that complies with your data sovereignty 
+and compliance requirements. Understanding the data sovereignty requirements 
+for any application being built on {+service+} is necessary to ensure you 
+stay compliant with proper governance. Additionally, {+service+} simplifies 
+data sovereignty compliance through global {+clusters+} with zoned sharding.
 
 You can use global {+clusters+} to control data storage locations. You can
 partition and store data in your database into distinct zones, each situated
@@ -144,8 +155,8 @@ Backup Snapshot Distribution
 
 You can distribute backup snapshots and oplog data across multiple regions.
 For example, you can satisfy compliance requirements and store backups in
-different, air-gapped geographical locations to ensure disaster recovery
-in case of regional outages. To learn more, see :atlas:`Snapshot Distribution <snapshot-distribution>`.
+different geographical locations to ensure disaster recovery
+in case of regional outages. To learn more, see `Snapshot Distribution <https://www.mongodb.com/docs/atlas/backup/cloud-backup/snapshot-distribution/>`__.
 
 .. _arch-center-compliance-backup-compliance-policy: