encryption of catalog item field post submission on portal and RITM

[dhivyal94299399]

Hi,

I have requirement, where i need to encrypt or mask the address field in the catalog form, post submission of the user in the portal and RITM. 

That shipping address is populated to the catalog task of the description, where i need to encrypt.

[Vikram Reddy]

Hi @dhivyal94299399 

Use a Masked catalog variable for the address and keep Use encryption enabled. This stores the catalog answer encrypted and controls viewing from the variable editor on the RITM/SCTASK side. Fulfillers who need to reveal it should have the catalog_view_masked role; others will not be able to use the Show/Hide behavior.

For Service Portal, show only the masked/encrypted variable through the standard catalog/request variable display. Do not copy the variable value into the request description, task description, comments, work notes, or notifications.

Thank you,

Vikram Karety

[dhivyal94299399]

@Vikram Reddy @Tanushree Maiti 

Then what is the use of field encryption module that is in servicenow

[Vikram Reddy]

Field Encryption is used when the sensitive value is stored in a normal ServiceNow table field or attachment and you want cryptographic protection on that stored data.

A masked/encrypted catalog variable protects the catalog variable answer.

Field Encryption protects table fields such as:

- sc_req_item.u_secure_shipping_address
- sc_task.u_secure_shipping_address
- incident.u_sensitive_details
- sn_hr_core_case.u_personal_id
- case.u_bank_account
- custom application fields
- supported attachments

So both features are useful, but they solve slightly different problems.

In your example, if the address is captured only as a catalog variable, then a Masked variable with Use encryption is the right starting point.

But if the business needs the address to be stored on the RITM or SCTASK as a field, then create a dedicated custom field, for example:

u_secure_shipping_address

Then configure Field Encryption on that field. Only authorized users/processes should have decrypt access.

What should be avoided is copying the address into common plain-text fields like:

- Description
- Short description
- Work notes
- Additional comments
- Activity
- Emails / notifications

If the address is copied into those fields, it becomes plain text there unless those specific fields are also encrypted. Field Encryption does not automatically protect every copied instance of the value.

Example:

Good design:

Catalog variable:
shipping_address = masked + encrypted

RITM/SCTASK custom field:
u_secure_shipping_address = Field Encryption enabled

Description:
"Shipping address is stored in a secured field/variable and is visible only to authorized users."

Bad design:

Description:
"Shipping Address: 123 Main Street..."

In the bad design, the address is exposed in the description, activity stream, search, reports, notifications, and integrations depending on configuration.

So the use of Field Encryption is:

Use it when you need to encrypt sensitive data stored in actual table fields or attachments, with role/policy-based decrypt access and stronger key management.

Use masked encrypted catalog variables when the sensitive data is captured as a catalog answer.

Use both if needed:

- Masked/encrypted variable for the portal/catalog submission.
- Field Encryption on a dedicated RITM/SCTASK custom field if the value must also be stored directly on the record.

Field Encryption is not a replacement for masked catalog variables. It is for encrypting supported table fields and attachments. For the catalog/RITM/Service Portal scenario, use the masked encrypted variable for the catalog answer, and use Field Encryption only if you also need to store that same address in a dedicated RITM/SCTASK field. Do not store the real address in description/comments/work notes unless those fields are intentionally encrypted and fully tested.

Thank you,

Vikram Karety

ServiceNow Architect

Octigo Solutions INC

[Tanushree Maiti]

Hi @dhivyal94299399 

As per my knowledge , Applying the Field Encryption (formerly Column Level Encryption) module to variables in a Requested Item (RITM) is not supported out-of-the-box because variables are stored as key-value pairs in the sc_item_option_mtom and sc_item_option  tables, rather than standard columns.

Use following articles to know more about field encrytption:

Unlocking the Power of Field Encryption in ServiceNow

Using Field Encryption