> ## Documentation Index
> Fetch the complete documentation index at: https://docs.parable.work/llms.txt
> Use this file to discover all available pages before exploring further.

# Data Encryption

> Customer-Managed Encryption Keys (CMEK) on Parable — control your own keys, rotate on your schedule, revoke access at any time, and audit every operation.

<Info>
  Customer-Managed Encryption Keys (CMEK) is available on Enterprise plans. Contact [support@askparable.com](mailto:support@askparable.com) to enable it for your organization.
</Info>

## What is CMEK?

By default, Parable encrypts your data at rest using Google-managed keys. With **Customer-Managed Encryption Keys (CMEK)**, you control the encryption keys used to protect your data — stored in **your** Google Cloud KMS keyring.

This gives you the ability to:

<CardGroup cols={2}>
  <Card title="Rotate Keys" icon="arrows-rotate">
    Generate new key versions on your schedule. New data is encrypted with the latest version; existing data remains readable under previous versions.
  </Card>

  <Card title="Disable Access" icon="ban">
    Disable your key to immediately revoke Parable's ability to decrypt your data — even in an emergency.
  </Card>

  <Card title="Audit Every Operation" icon="clipboard-list">
    Google Cloud Audit Logs record every encrypt and decrypt operation with full identity context.
  </Card>

  <Card title="Schedule Key Destruction" icon="clock">
    Schedule key versions for destruction after a 24-hour waiting period (GCP-enforced).
  </Card>
</CardGroup>

## What Parable controls vs. what you control

|                          | Parable                                                                                                            | You                                                                 |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------- |
| **KMS keyring creation** | ✓ Created during provisioning                                                                                      | —                                                                   |
| **Keyring location**     | Set to your data region                                                                                            | —                                                                   |
| **Key rotation**         | Automatic every 90 days                                                                                            | Can manually trigger anytime                                        |
| **Encrypt / decrypt**    | ✓ Application service accounts use keys to process your data                                                       | —                                                                   |
| **Key disable / enable** | Infrastructure admins retain access for operational purposes but will never act without your written authorization | ✓ Can disable or enable at any time                                 |
| **Key destruction**      | Infrastructure admins retain access for operational purposes but will never act without your written authorization | ✓ Can schedule destruction                                          |
| **Audit log access**     | Internal monitoring                                                                                                | ✓ Read-only access to your keyring's audit logs via scoped log view |

<Warning>
  **Disabling your key immediately stops all Parable services from accessing your data.** Ingestion jobs will fail, and dashboards will return errors until you re-enable the key. See the **Incident Response** tab below for the full impact guide.
</Warning>

## Your keyring in GCP

When Parable provisions your account, we create a dedicated KMS keyring for you in Parable's GCP project. You receive IAM access to your keyring only — you cannot see other customers' keyrings, and they cannot see yours.

* **Keyring name:** `tenant-{your-slug}-kms`
* **Location:** Same region as your data (e.g., `us-east1`)
* **Keys in the keyring:**
  * `main` — Symmetric key for encrypting data at rest (auto-rotates every 90 days)
  * `credential-encryption` — Asymmetric key for encrypting connector credentials in transit

Parable supports two sign-in methods to reach GCP Console:

* **Corporate SSO (recommended)** — Sign in with your existing identity provider (Okta, Azure AD, JumpCloud, etc.) via a federated sign-in link. No Google account needed. Your IT admin controls access through your IdP. See the **SSO Setup** tab.
* **Google account** — If your organization uses Google Workspace, sign in directly with your Google account.

During onboarding, Parable configures your preferred access method and provides direct links to your keyring and audit logs.

***

<Tabs>
  <Tab title="SSO Setup" icon="shield-halved">
    During CMEK onboarding, your IT admin creates an SSO application in your identity provider so your team can access GCP Console to manage encryption keys and view audit logs. This tab gives your IT admin everything they need.

    <Info>
      Parable provides the values marked **from Parable** during onboarding. If you don't have them yet, contact [support@askparable.com](mailto:support@askparable.com).
    </Info>

    ### Choose your protocol

    Most identity providers support both OIDC and SAML. OIDC is simpler to set up — use it unless your organization requires SAML.

    <Tabs>
      <Tab title="OIDC" icon="key">
        ### OIDC application setup

        Create a new **Custom OIDC** application in your identity provider with these settings:

        | Setting               | Value                                                 |
        | --------------------- | ----------------------------------------------------- |
        | App name              | `Parable CMEK Access` (or any name your team prefers) |
        | Redirect URI          | *Provided by Parable*                                 |
        | Login URL             | *Provided by Parable*                                 |
        | Grant type            | Authorization Code                                    |
        | Client authentication | Client Secret Basic                                   |
        | Scopes                | `openid`, `profile`, `email`                          |

        <Steps>
          <Step title="Create the OIDC application">
            In your IdP admin console, create a new custom OIDC application. Enter the **Redirect URI** and **Login URL** provided by Parable.
          </Step>

          <Step title="Assign users or groups">
            Assign the users or groups who should have access to your encryption keys. Anyone assigned to this application can sign in — you can add or remove users at any time without contacting Parable.
          </Step>

          <Step title="Send credentials to Parable">
            Share the following with your Parable contact (via a secure channel such as 1Password or your organization's preferred method):

            * **Client ID**
            * **Client Secret**
            * **Issuer URL** (e.g. `https://your-org.okta.com/` or `https://oauth.id.jumpcloud.com/`)
          </Step>

          <Step title="Parable completes configuration">
            Parable configures the federation and sends you back:

            * A **sign-in link** for GCP Console
            * A **direct link** to your encryption keyring
            * A **direct link** to your audit logs

            Your team can also access GCP Console from the app in your IdP's portal.
          </Step>
        </Steps>

        <AccordionGroup>
          <Accordion title="Okta">
            1. Go to **Applications → Create App Integration → OIDC - OpenID Connect → Web Application**
            2. Set the **Sign-in redirect URI** to the Redirect URI from Parable
            3. Under **Assignments**, assign the relevant users or groups
            4. Copy the **Client ID** and **Client Secret** from the app's General tab
            5. Your Issuer URL is `https://your-org.okta.com/`
          </Accordion>

          <Accordion title="Azure AD (Microsoft Entra ID)">
            1. Go to **App registrations → New registration**
            2. Set the **Redirect URI** (Web) to the Redirect URI from Parable
            3. Under **Certificates & secrets**, create a new client secret
            4. Copy the **Application (client) ID** and the **secret value**
            5. Your Issuer URL is `https://login.microsoftonline.com/{tenant-id}/v2.0`
          </Accordion>

          <Accordion title="JumpCloud">
            1. Go to **SSO Applications → Add New Application → Custom OIDC App**
            2. Set **Redirect URI** and **Login URL** from Parable
            3. Set **Client Authentication Type** to **Client Secret Basic**
            4. Check **Email** and **Profile** under Standard Scopes
            5. Assign your test user or group
            6. Copy the **Client ID** and **Client Secret**
            7. Issuer URL is `https://oauth.id.jumpcloud.com/`
          </Accordion>
        </AccordionGroup>
      </Tab>

      <Tab title="SAML 2.0" icon="lock">
        ### SAML application setup

        Create a new **Custom SAML** application in your identity provider with these settings:

        | Setting                 | Value                                                 |
        | ----------------------- | ----------------------------------------------------- |
        | App name                | `Parable CMEK Access` (or any name your team prefers) |
        | SP Entity ID (Audience) | *Provided by Parable*                                 |
        | ACS URL (Reply URL)     | *Provided by Parable*                                 |
        | Login URL               | *Provided by Parable*                                 |
        | NameID Format           | Email or Persistent                                   |

        <Warning>
          Your SAML application **must** have the HTTP-Redirect binding enabled. GCP requires this for browser-based single sign-on. In most IdPs, this is a checkbox like "Declare Redirect Endpoint" or "Enable HTTP-Redirect binding."
        </Warning>

        <Steps>
          <Step title="Create the SAML application">
            In your IdP admin console, create a new custom SAML application. Enter the **SP Entity ID**, **ACS URL**, and **Login URL** provided by Parable.

            Make sure to enable the **HTTP-Redirect** SSO binding (not just HTTP-POST).
          </Step>

          <Step title="Assign users or groups">
            Assign the users or groups who should have access to your encryption keys. Anyone assigned to this application can sign in — you can add or remove users at any time without contacting Parable.
          </Step>

          <Step title="Send metadata to Parable">
            Share your **IdP Metadata XML** with Parable. This is typically available as:

            * A **metadata URL** (e.g. `https://sso.jumpcloud.com/saml2/metadata/...`) — preferred
            * A downloadable **XML file** from your IdP's app settings
          </Step>

          <Step title="Parable completes configuration">
            Parable configures the federation and sends you back:

            * A **sign-in link** for GCP Console
            * A **direct link** to your encryption keyring
            * A **direct link** to your audit logs

            Your team can also access GCP Console from the app in your IdP's portal.
          </Step>
        </Steps>

        <AccordionGroup>
          <Accordion title="Okta">
            1. Go to **Applications → Create App Integration → SAML 2.0**
            2. Set **Single sign-on URL** to the ACS URL from Parable
            3. Set **Audience URI (SP Entity ID)** to the SP Entity ID from Parable
            4. Under **SAML Settings → Show Advanced Settings**, ensure **Response** is set to **Signed**
            5. Under **Assignments**, assign the relevant users or groups
            6. Copy the **Metadata URL** from the app's Sign On tab
          </Accordion>

          <Accordion title="Azure AD (Microsoft Entra ID)">
            1. Go to **Enterprise applications → New application → Create your own application → Non-gallery**
            2. Under **Single sign-on → SAML**, set:
               * **Identifier (Entity ID)** to the SP Entity ID from Parable
               * **Reply URL (ACS URL)** to the ACS URL from Parable
            3. Download the **Federation Metadata XML** from the SAML Signing Certificate section
            4. Assign users or groups under **Users and groups**
          </Accordion>

          <Accordion title="JumpCloud">
            1. Go to **SSO Applications → Add New Application → Custom SAML App**
            2. Set **IdP Entity ID** to a unique identifier (e.g. `https://jumpcloud.com/parable-customer-{slug}`)
            3. Set **SP Entity ID** and **ACS URL** from Parable
            4. Enable **Declare Redirect Endpoint** (required by GCP)
            5. Assign your test user or group
            6. Copy the **Metadata URL** from the app's SSO tab (e.g. `https://sso.jumpcloud.com/saml2/metadata/...`)
          </Accordion>
        </AccordionGroup>
      </Tab>
    </Tabs>

    ### What happens after setup

    Once Parable completes the federation:

    * **You control access.** Add or remove users from the SSO application in your IdP at any time. Changes take effect immediately — no Parable involvement needed.
    * **No Google account required.** Your team signs in with their existing corporate credentials.
    * **No Terms of Service to accept.** Federated users are temporary users of Parable's GCP project, covered by Parable's existing agreement with Google.

    If you need to change your IdP or rotate credentials, contact [support@askparable.com](mailto:support@askparable.com).
  </Tab>

  <Tab title="Key Management" icon="gear">
    ### Navigating to your keyring

    <Steps>
      <Step title="Sign in to GCP Console">
        Parable supports two sign-in methods depending on your organization's setup:

        * **Corporate SSO** — Use the federated sign-in link provided by Parable during onboarding. This redirects through your identity provider (Okta, Azure AD, JumpCloud, etc.) — no Google account needed.
        * **Google account** — If your organization uses Google Workspace, sign in directly at [console.cloud.google.com](https://console.cloud.google.com) with your Google account.

        If you don't have your sign-in link, contact [support@askparable.com](mailto:support@askparable.com).
      </Step>

      <Step title="Open your keyring directly">
        Parable provides a direct link to your keyring during onboarding. Use this link — it takes you straight to your keys without needing to browse the project.

        <Info>
          Your access is scoped to your keyring only. You will not be able to list or browse other keyrings in the project.
        </Info>
      </Step>

      <Step title="Verify your keys">
        You should see two keys:

        * **`main`** — Symmetric key for encrypting your data at rest (auto-rotates every 90 days)
        * **`credential-encryption`** — Asymmetric key for encrypting connector credentials in transit
      </Step>
    </Steps>

    ### Key rotation

    Key rotation creates a new key **version**. Existing data encrypted with previous versions remains readable — GCP tracks which version was used for each encryption and decrypts automatically.

    <Steps>
      <Step title="Select the key">
        In your keyring, click on the `main` key.
      </Step>

      <Step title="Rotate the key">
        Click **Rotate key** in the top toolbar.

        Review the confirmation dialog and click **Rotate key** to confirm.
      </Step>

      <Step title="Verify the new version">
        The key list shows the new version as **Primary**. Previous versions remain **Enabled** and continue to decrypt data encrypted under them.
      </Step>
    </Steps>

    <Info>
      Parable automatically rotates your `main` key every 90 days. Manual rotation creates an additional version ahead of schedule — this does not reset the automatic rotation timer.
    </Info>

    ### Disable a key version

    Disabling a key version prevents GCP from using it for any encrypt or decrypt operations. This immediately blocks Parable from accessing data encrypted under that version.

    <Warning>
      **Disabling the primary (current) key version will cause Parable services to fail immediately.** Only do this if you intend to stop all data access. See the **Incident Response** tab for recovery steps.
    </Warning>

    <Steps>
      <Step title="Open the key version">
        In your keyring, click the key name, then click the three-dot menu on the key version row.
      </Step>

      <Step title="Disable the version">
        Select **Disable**. Confirm in the dialog.

        The version status changes to **Disabled** immediately.
      </Step>
    </Steps>

    ### Re-enable a key version

    <Steps>
      <Step title="Open the disabled key version">
        Find the version with **Disabled** status in the key version list.
      </Step>

      <Step title="Re-enable">
        Click the three-dot menu → **Enable**. Confirm in the dialog.

        The version status returns to **Enabled** (or **Primary** if it was the primary version).
      </Step>

      <Step title="Parable services recover automatically">
        Within 60 seconds, Parable's services detect the key is available again and resume normal operation. No action required on your end.
      </Step>
    </Steps>

    ### Schedule key version destruction

    Destroying a key version permanently deletes the key material. **This is irreversible.** Any data encrypted exclusively by this version becomes permanently unreadable.

    <Warning>
      **Do not destroy the primary key version or any version that encrypted data you still need.** Before destroying a version, ensure Parable has re-encrypted all data under a newer version. Contact [support@askparable.com](mailto:support@askparable.com) before proceeding.
    </Warning>

    <Steps>
      <Step title="Schedule for destruction">
        Click the three-dot menu on the key version → **Schedule destruction**.

        GCP enforces a **minimum 24-hour waiting period** before the key material is deleted. You can cancel during this window.
      </Step>

      <Step title="Cancel if needed">
        If you change your mind, click **Cancel destruction** before the waiting period expires.
      </Step>
    </Steps>

    ### Audit logs

    Every encrypt, decrypt, and key management operation on your KMS keys is recorded in **Google Cloud Audit Logs**. You have read-only access to a dedicated log view that contains only your organization's KMS operations — no other customer's data is visible.

    <Steps>
      <Step title="Open Cloud Logging">
        Sign in to GCP Console using your federated sign-in link or Google account (see the steps above). Then go to **Logging → Logs Explorer**. You can find it under the **Observability** section in the left navigation, or by searching for "Logs Explorer" in the top search bar.
      </Step>

      <Step title="Select your log view">
        Click **Refine scope** (near the top of the query panel) → **Log view** → select `tenant-{your-slug}-kms-audit`.
      </Step>

      <Step title="Run the query">
        Click **Run query**. You'll see log entries for every KMS operation on your keys. All results are scoped to your organization.
      </Step>
    </Steps>

    #### Common log filters

    <AccordionGroup>
      <Accordion title="See all encrypt operations" icon="lock">
        ```
        resource.type="cloudkms_cryptokey"
        resource.labels.key_ring_id="tenant-{your-slug}-kms"
        protoPayload.methodName="Encrypt"
        ```
      </Accordion>

      <Accordion title="See all decrypt operations (who accessed your data)" icon="unlock">
        ```
        resource.type="cloudkms_cryptokey"
        resource.labels.key_ring_id="tenant-{your-slug}-kms"
        protoPayload.methodName="Decrypt"
        ```
      </Accordion>

      <Accordion title="See key management events (rotations, disables, enables)" icon="gear">
        ```
        resource.type="cloudkms_cryptokey"
        resource.labels.key_ring_id="tenant-{your-slug}-kms"
        protoPayload.methodName=~"(DestroyCryptoKeyVersion|ScheduleCryptoKeyVersionDestruction|RestoreCryptoKeyVersion|UpdateCryptoKey)"
        ```
      </Accordion>

      <Accordion title="See access by a specific identity" icon="user">
        ```
        resource.type="cloudkms_cryptokey"
        resource.labels.key_ring_id="tenant-{your-slug}-kms"
        protoPayload.authenticationInfo.principalEmail="service-account@project.iam.gserviceaccount.com"
        ```
      </Accordion>
    </AccordionGroup>

    #### Log entry fields

    | Field                                            | Description                                         |
    | ------------------------------------------------ | --------------------------------------------------- |
    | `protoPayload.methodName`                        | The KMS operation (e.g., `Encrypt`, `Decrypt`)      |
    | `protoPayload.authenticationInfo.principalEmail` | Who or what service account performed the operation |
    | `protoPayload.resourceName`                      | The full resource path of the key version used      |
    | `timestamp`                                      | When the operation occurred                         |
    | `protoPayload.response.name`                     | The key version name that was used                  |

    <Info>
      KMS Data Access audit logs (encrypt/decrypt operations) are enabled on the Parable project. Key management events (rotations, disables, destruction) are logged as Admin Activity and are always on.
    </Info>

    To receive exports of your KMS audit logs for your SIEM or compliance records, contact [support@askparable.com](mailto:support@askparable.com).
  </Tab>

  <Tab title="Incident Response" icon="triangle-exclamation">
    This tab covers what to do if you need to disable your encryption key as part of a security incident — and exactly what happens to Parable services when you do.

    ### Scenario: you disable your key at 2 AM

    #### What happens immediately

    When you disable a key version, GCP stops honoring encrypt/decrypt requests for that version **within seconds**. Here's the cascade:

    | Time    | What happens                                                                        |
    | ------- | ----------------------------------------------------------------------------------- |
    | T+0s    | Key disabled in GCP KMS                                                             |
    | T+5–30s | In-flight Parable API requests that require decryption start returning 500 errors   |
    | T+60s   | Parable's background services detect the key failure and stop retrying              |
    | T+2–5m  | Connector ingestion jobs fail with `KMS_KEY_DISABLED` error                         |
    | T+5m    | Parable on-call receives an alert about key failures (we monitor decryption errors) |

    **Your dashboards will show errors until the key is re-enabled.** No data is lost — encrypted data remains intact on disk, inaccessible until the key is available again.

    #### Parable will not re-enable your key without authorization

    Parable's application service accounts can only use keys (encrypt/decrypt), not manage them. Parable's infrastructure administrators have broader access for operational purposes, but will **never** re-enable your key without your explicit written authorization.

    ### Recovery: re-enabling the key

    <Steps>
      <Step title="Sign in to GCP Console">
        Sign in using your federated sign-in link or Google account, then navigate to your keyring: **Security → Key Management** → `tenant-{your-slug}-kms`.
      </Step>

      <Step title="Re-enable the key version">
        Find the disabled version, click the three-dot menu → **Enable**.

        Confirm in the dialog. The status changes to **Enabled** immediately.
      </Step>

      <Step title="Services recover automatically">
        Parable's services retry failed operations and resume normal function within **60 seconds** — no action needed on your end and no need to contact support unless issues persist after 5 minutes.
      </Step>

      <Step title="Check for stuck ingestion jobs">
        Ingestion jobs that failed mid-run will not automatically retry. In Parable, go to **Connectors** and manually trigger a sync for any connectors showing errors.
      </Step>
    </Steps>

    ### Checklist: disabling your key

    Use this checklist before disabling your key in a security incident:

    1. Notify your Parable account manager or email [support@askparable.com](mailto:support@askparable.com) — we can help triage whether KMS disable is the right response
    2. Note the current time — you'll need it for audit log review later
    3. Disable the key in GCP Console (see the **Key Management** tab)
    4. Confirm Parable services show errors (expected) — verify at least one API call fails
    5. Document the incident and gather audit logs for the period before the disable (see **Key Management → Audit logs**)
    6. When the incident is resolved, re-enable the key (steps above)
    7. Trigger manual syncs for any connectors that failed during the outage

    ### Incident-time FAQ

    <AccordionGroup>
      <Accordion title="Can Parable access my data when my key is disabled?" icon="lock">
        No. When the key is disabled, GCP refuses all decrypt operations — including those from Parable's service accounts. Your data is inaccessible to everyone, including Parable.
      </Accordion>

      <Accordion title="Will disabling my key affect other Parable customers?" icon="users">
        No. Each customer has their own isolated keyring. Disabling your key only affects your organization.
      </Accordion>

      <Accordion title="What if I schedule my key for destruction by mistake?" icon="trash-arrow-up">
        You have a **minimum 24-hour window** to cancel scheduled destruction. Navigate to the key version and click **Cancel destruction** immediately. Contact [support@askparable.com](mailto:support@askparable.com) for guidance.
      </Accordion>
    </AccordionGroup>

    See the **FAQ** tab for more questions about CMEK.
  </Tab>

  <Tab title="FAQ" icon="circle-question">
    <AccordionGroup>
      <Accordion title="Do I need a Google account to manage my keys?" icon="google">
        **Not necessarily.** Parable supports two ways to access your keyring in GCP Console:

        1. **Corporate SSO (recommended)** — Parable configures Workforce Identity Federation so you can sign in with your existing identity provider (Okta, Azure AD, JumpCloud, Ping Identity, or any OIDC or SAML 2.0 IdP). Your IT admin creates an SSO application and provides Parable with the connection details during onboarding. Anyone your IT admin assigns to the application in your IdP gets access automatically — no per-user setup on Parable's side.

        2. **Google account** — If your organization already uses Google Workspace, you can access GCP Console directly with your existing Google account. Parable grants access to specific email addresses.

        During onboarding, Parable will work with you to determine which option fits your organization best.
      </Accordion>

      <Accordion title="What happens to existing data when I rotate my key?" icon="arrows-rotate">
        **Nothing changes immediately.** Data encrypted under the old key version remains readable — GCP tracks which key version encrypted each object and automatically uses the right version to decrypt.

        Over time, as Parable writes new data (credentials, ingestion results), it uses the new primary key version. Old data is only re-encrypted if Parable explicitly triggers re-encryption, which we do not do automatically.

        This means both versions remain active (Enabled) in your keyring even after rotation.
      </Accordion>

      <Accordion title="Can Parable re-enable a key that I've disabled?" icon="key">
        Parable's application service accounts hold `roles/cloudkms.cryptoKeyEncrypterDecrypter`, which allows encrypt and decrypt operations but **not** the ability to enable or disable keys. However, Parable's infrastructure administrators do have `roles/cloudkms.admin` access for operational purposes (e.g., disaster recovery, tenant provisioning).

        In practice, Parable will **never** re-enable your key without your explicit written authorization.
      </Accordion>

      <Accordion title="Can Parable read my credentials if my key is enabled?" icon="eye">
        Parable only decrypts credentials when processing an ingestion job on your behalf. Every decrypt operation is recorded in Cloud Audit Logs (see **Key Management → Audit logs**) with the service account identity and timestamp. You have full visibility into every access.
      </Accordion>

      <Accordion title="What happens if I destroy a key version?" icon="trash">
        Destroying a key version permanently deletes the key material. Any data encrypted exclusively by that version becomes **permanently unreadable** — this cannot be undone.

        GCP enforces a minimum 24-hour waiting period before destruction completes, giving you time to cancel. If you've destroyed a version that Parable still needs, contact [support@askparable.com](mailto:support@askparable.com) immediately — we may be able to help assess the impact, but data recovery may not be possible.
      </Accordion>

      <Accordion title="How often does Parable rotate my key automatically?" icon="clock">
        The `main` symmetric key is set to auto-rotate every **90 days**. The `credential-encryption` asymmetric key does not auto-rotate (asymmetric keys require manual version management). You can manually rotate either key at any time from GCP Console.
      </Accordion>

      <Accordion title="Does CMEK protect data in transit?" icon="shield-check">
        CMEK specifically covers encryption **at rest** (stored data). Data in transit is always protected with **TLS 1.2+** regardless of your CMEK configuration. For credential transport specifically, Parable uses RSA-OAEP-4096 asymmetric encryption via your `credential-encryption` KMS key — credentials are encrypted client-side before they reach Parable servers.
      </Accordion>

      <Accordion title="Is my keyring in my GCP project or Parable's?" icon="folder-tree">
        Your keyring is in **Parable's GCP project**, not in your own GCP project. This is because Parable's infrastructure services need to perform encrypt/decrypt operations on behalf of your account.

        You have IAM access to your specific keyring — you cannot see other customers' keyrings, and other customers cannot see yours. You sign in to GCP Console via your corporate SSO (federated sign-in link) or your Google account, depending on your organization's setup.
      </Accordion>

      <Accordion title="What compliance standards does CMEK help me meet?" icon="file-certificate">
        CMEK supports compliance requirements around key custody and auditability, including:

        * **SOC 2** — Demonstrates you control access to encrypted data
        * **GDPR / data erasure** — Destroying your encryption key is a recognized method of cryptographic erasure
        * **HIPAA / HITRUST** — Provides audit trails for all data access operations
        * **ISO 27001** — Supports A.10 (Cryptography) controls

        Consult your compliance team to determine whether CMEK satisfies your specific requirements.
      </Accordion>

      <Accordion title="How do I find my organization's slug?" icon="tag">
        Your slug is the URL-safe identifier for your organization. You can find it in Parable's admin settings, or ask your Parable account manager. It appears in your keyring name: `tenant-{your-slug}-kms`.
      </Accordion>
    </AccordionGroup>
  </Tab>
</Tabs>

***

<Tip>
  Questions we haven't covered? Reach out to [support@askparable.com](mailto:support@askparable.com) or your Parable account manager.
</Tip>