Skip to main content
Skip table of contents

Personal Identifiable Information (PII) guidelines

Last Updated:

PII storage and processing restrictions

VA PII may never be stored on, processed on, or transmitted through non-VA assets.

  • ❌ DO NOT email files containing PII to non-VA email addresses.

  • ❌ DO NOT store or process PII on non-VA computers.

  • ❌ DO NOT store PII within non-VA cloud services such as Google Drive, even temporarily.

PII CAN be stored and processed using:

  • ✅ VA government-furnished equipment

  • ✅ VA Azure Virtual Desktop or VA Citrix Access Gateway

  • ✅ VA.gov AWS account

If you need to store or process PII but you cannot access approved methods, please reach out to platform support for assistance at #vfs-platform-support.

This document covers the rules, processes, and requirements for dealing with any personally identifiable information (PII) collected or stored by the VSP platform. These guidelines are intended to protect the privacy and security of VA.gov users and comply with federal privacy regulations.

OMB memorandum M-07-16 includes extensive details about securing PII, including this brief definition:

The term "personally identifiable information" refers to information which can be used to distinguish or trace an individual's identity, such as their name, social security number, biometric records, etc. alone, or when combined with other personal or identifying information which is linked or linkable to a specific individual, such as date and place of birth, mother’s maiden name, etc.

We expect developers to use the minimum amount of PII required by their application and be aware of where and how that data is stored throughout the web request lifecycle.

Existing capabilities

There are several points in the web request lifecycle where PII can be filtered or sanitized in the vets-api application:

This should ensure most PII is filtered automatically. If your application interacts with any new PII, especially from a new data source, you should ensure that the PII is filtered in both the Rails log and in any errors thrown by the application. You may need to add new PII fields to the Sentry PII sanitizer.

PII with the PersonalInformationLog

If you must log PII to implement a specific solution, the VSP application does have a PersonalInformationLog which is designed to store PII. This can be useful for tracking the data relating to specific errors involving PII, logging PII during the rollout of new features, or running scheduled tasks that require access to PII.

Any use of the PersonalInformationLog will require additional review from the platform engineering team and you are advised to discuss the need for storing PII early in the development process.

Notes and policies regarding ICNs

Veterans with whom VA interacts, as well as beneficiaries, employees, IT users, healthcare providers, and others whom the VA interacts with, are assigned unique Integration Control Numbers (ICNs). The VA's authoritative identity service, which both stores identity information and assigns ICNs, is the Master Person Index (MPI).

Contrary to what you may have heard, ICNs are PII and should be treated as such. This means, among other things:

  • no storing them in systems not authorized to store PII, such as Datadog, Sentry, Google Analytics, and Domo;

  • no storing them in unencrypted database fields unless necessary to solve a technical problem for which no other solution is feasible;

  • no storing datasets containing them on non-GFE; and

  • no viewing or accessing them without a legitimate business purpose.

In addition, apps built on VA.gov should avoid using ICNs to link stored data to specific VA.gov users; the user_account_uuid value should be used instead. More generally, ICNs should be stored in as few locations as possible.

Uniquely identifying users in logs

As noted above, a user's user_account_uuid can be used to link stored data to specific VA.gov users. This includes in logs sent to Datadog, Sentry, etc., i.e., it is permissible to include the user_account_uuid in log messages so that those logs can be linked back to the VA.gov user they're associated with.

From the fact that they are allowed to log user_account_uuid values, developers sometimes erroneously conclude, "That must mean that user_account_uuid values are not PII!" This is a common enough misconception that clarification is in order.

Any identifier which can be used to uniquely identify an individual is considered PII. There are two reasons why, despite this, we allow user_account_uuid to be logged:

  • We are required by law and VA policy to limit our storage and use of PII to what is necessary to provide services. It would simply be too hard for us to operate VA.gov if it were impossible for us to ever associate log entries with specific users. That is, we need to be able to log some unique identifier, and this requirement is one of the reasons why user_account_uuid exists.

  • Because user_account_uuid is randomly generated, i.e., there is no objective meaning about specific individuals that can be derived from it, and it is only used within VA.gov and its supporting systems such as Datadog. By design, its Confidentiality Impact Level is low, giving us more leeway in how it can be used.

An open source reminder

Much of the Platform code, including vets-api and vets-website is open source and available to anyone through GitHub. This means that you should be particularly careful about embedding anything that could be PII in your code, especially in tests.

Common PII that you should avoid:

If you have any questions about PII and protecting it, you should discuss it with your project lead or request help from the Platform in Slack.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.

Contact Support Close