Improvements to Key management for encryption at rest page

Some low hanging fruit that jumped out at me.

src/content/docs/security/security-privacy/compliance/key-management-encryption-rest.mdx

@@ -9,19 +9,19 @@ redirects:
   - /docs/security/new-relic-security/compliance/key-management-encryption-rest
 ---
 
-For customers with heightened regulatory or privacy needs, New Relic offers account-based, [FIPS-compliant](https://csrc.nist.gov/publications/detail/fips/140/2/final) encryption-at-rest capabilities with unique keys per account. This protects data from inadvertent or intentional exposure, even if the attacker has access to the filesystem.
+For customers with heightened regulatory or privacy needs, New Relic offers account-based, [FIPS-compliant](https://csrc.nist.gov/publications/detail/fips/140/2/final) encryption-at-rest capabilities with unique keys per account. This protects data from inadvertent or intentional exposure, even if an attacker has access to the file system.
 
-To achieve a high level of protection while maintaining high performance and long-term storage and retrieval of data, we use a two-tier system consisting of a data encryption key (DEK) and a master key, each with separate usage, storage, and rotation policies.
+It's important to maintain both a high level of protection and also optimal performance and long-term storage and retrieval of data. To do this, New Relic uses a two-tier system consisting of a data encryption key (DEK) and a master key, each with separate usage, storage, and rotation policies.
 
-For an overview of how we handle your data in transit and at rest, see our [data encryption documentation](/docs/security/new-relic-security/compliance/data-encryption). This document describes the key management process for data encryption in more detail.
+For an overview of how we handle your data in transit and at rest, including details about the key management process for data encryption, see [data encryption documentation](/docs/security/new-relic-security/compliance/data-encryption).
 
 ## Encryption and decryption process [#process]
 
 When encryption at rest is enabled for an account, each new file is encrypted (AES-GCM with 256 bit keys) with a data encryption key that is unique to the account and the server writing the data. Each DEK is generated locally using a FIPS 140-2 validated cryptographic module on the server. Each account’s DEK is rotated every 24 hours or when it has been used to encrypt 64 GB of data. It can also be rotated manually, as-needed.
 
 The DEK that is used to encrypt a file is subsequently encrypted with the Master Key and appended in this wrapped format onto the encrypted data file. The key is encrypted remotely on our key management service (KMS), which is provided by [AWS](https://aws.amazon.com/kms/).
 
-In order to read a file, the process is reversed: First, the NRDB host on which the data resides extracts the wrapped DEK from the file and sends it to the KMS to be decrypted (unwrapped). Finally, the host decrypts the data file and processes it.
+In order to read a file, the process is reversed: First, the [NRDB](/docs/telemetry-data-platform/get-started/nrdb-horsepower-under-hood/) host on which the data resides extracts the wrapped DEK from the file and sends it to the KMS to be decrypted (unwrapped). Finally, the host decrypts the data file and processes it.
 
 ## Key rotation [#rotation]
 
@@ -31,9 +31,9 @@ The master key is used only to encrypt DEKs, so a ciphertext attack against it i
 
 ## Key handling
 
-New Relic servers generate each DEK locally, and the plain text DEK is never written to disk. If an attacker gained access to process memory, they could retrieve the unencrypted DEK for that server and time period, but they would be unable to read data from other time periods.
+New Relic servers generate each DEK locally, and the plain text DEK is never written to disk. If an attacker gained access to process memory, they could retrieve the unencrypted DEK for that server and time period, but they would be unable to read data from any other time periods.
 
-The Master key is generated, stored, and used within a FIPS 140-2 validated hardware security module (HSM) on the KMS. Neither New Relic nor AWS employees can retrieve the plaintext of the master key. Secure generation, management, backup, storage, and destruction are all handled and guaranteed by the KMS. Administrator access to key management functions is controlled and audited using AWS permissions and CloudTrail.
+The Master key is generated, stored, and used within a FIPS 140-2 validated hardware security module (HSM) on the KMS. Neither New Relic nor AWS employees can retrieve the plain text of the master key. Secure generation, management, backup, storage, and destruction are all handled and guaranteed by the KMS. Administrator access to key management functions is controlled and audited using AWS permissions and CloudTrail.
 
 ## FedRAMP authorization [#fedramp]