Anonymization of encrypted columns

  • Release version: Australia
  • Updated June 16, 2026
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Anonymization of encrypted columns

    ServiceNow enables anonymization of columns protected by Column Level Encryption (CLE) as part of data privacy policies. This capability supports compliance requirements that demand data anonymization beyond encryption, such as data subject erasure requests. When anonymization is applied to encrypted columns, the system securely decrypts the data, anonymizes it, and then re-encrypts the result for storage, maintaining data protection throughout the process.

    Show full answer Show less

    Prerequisites

    • The Data Privacy Store application must be installed.
    • The Field Encryption Starter plugin must be active.
    • The system property dp.job.enablemapcreation must be set to true. Only users with snkmf.admin or snkmf.cryptographicmanager roles can modify this.

    All these prerequisites must be met before activating policies, creating, or scheduling anonymization jobs on encrypted columns. The system will provide error messages if any condition is missing. Note that anonymization on encrypted columns is not supported if there is an active encrypted row configuration on the same column, preventing policy activation and job scheduling in such cases.

    Admin Consent

    Since anonymizing encrypted columns modifies the encrypted data, explicit consent from a Data Privacy Admin is required before the job executes. The system prompts the admin to acknowledge this impact during job execution, listing the encrypted columns processed. If anonymization is not desired, selecting the No Action technique allows jobs to run without changing encrypted columns.

    How Anonymization Works on Encrypted Columns

    • The system decrypts the data using the column’s cryptographic modules.
    • Applies the chosen anonymization technique.
    • Re-encrypts the anonymized data and stores it securely.

    Post-anonymization, data remains accessible to users who had prior access. This process supports multi-module encryption and hierarchical tables, including CLE-encrypted journal fields, which remain encrypted after anonymization. If a job is rolled back, encrypted data reverts to the original plaintext values.

    Error Handling

    If decryption or encryption fails during the job, the system logs one error per table-column to prevent duplicate entries, helping maintain job integrity and troubleshooting clarity.

    When creating data privacy policies, you may include columns that are also protected by Column Level Encryption (CLE). How you handle those columns depends on your organization’s compliance requirements.

    If you consider encryption sufficient protection for the data, you can configure the policy to take no action on those columns. If your requirements demand that the data itself be anonymized—for example, to fulfill a data subject erasure request—the system supports running anonymization directly on encrypted columns.

    When anonymization runs on a CLE-encrypted column, the system decrypts the data, applies the anonymization technique, and re-encrypts the result before storing it in the database. This process requires specific prerequisites to be in place and explicit admin consent before a job can run.

    Prerequisites

    Before you can run an anonymization job on CLE-encrypted columns, the following must be true:

    • The Data Privacy Store application is installed.
    • The Field Encryption Starter plugin is active.
    • The glide property dp.job.enable_map_creation is set to true. Only users with the sn_kmf.admin or sn_kmf.cryptographic_manager role can modify this property.
    If any of these conditions are not met, the system will display an error message identifying the missing item. You will not be able to activate a policy, create a job, or schedule a job until all prerequisites are satisfied. These validations occur at policy creation, job creation, and job scheduling.
    Note:

    Anonymization of encrypted columns is not supported when an active row encryption configuration exists on the same column. If a policy includes a CLE-encrypted column that also has an active encrypted row configuration, the system will block policy activation and job scheduling and display a message identifying the conflict.

    Admin consent

    Because anonymizing an encrypted column removes the encryption protection from that data, the system requires explicit in-product consent from a Data Privacy Admin before a job can execute.

    When you run a data privacy job that includes encrypted columns, a prompt will appear asking you to click OK to acknowledge that the job will conflict with the existing encryption on those columns. The acknowledgement is recorded at the job level and includes a list of which encrypted columns were processed.

    If you do not wish to anonymize the encrypted data, you can instead select the No Action anonymization technique when creating the policy. This allows the job to run without altering the encrypted columns.

    How anonymization works on encrypted columns

    When a job runs on a CLE-encrypted column, the system:

    • Decrypts the data using the cryptographic modules associated with the column.
    • Applies the configured anonymization technique.
    • Re-encrypts the result and stores it in the database.

    After anonymization, the data remains visible to users who had access to it before the job ran. Anonymization is supported for columns encrypted using the multi-module method and for hierarchical table configurations.

    Journal fields: CLE-encrypted journal fields are also supported. After anonymization, journal fields remain encrypted.

    Rollback: If a job is rolled back, encrypted data remains encrypted. Decrypting the data after rollback will return the original plain-text values.

    Error handling

    If decryption or encryption fails for any column during a job, an error is logged. Only one error is logged per table-column combination to avoid duplicate entries.