Skip to main content
Skip table of contents

Sensitive documentation guidance

This document clarifies what content should live in the publicly-visible repository vs. the not-publicly-visible repository.


All content related to development on belongs in the public repository when possible. However, there are a limited number of reasons that content should remain private. All content in the repository should fall within one of the following approved use cases.

Private content


Veteran PII should not be checked into GitHub.

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.

Issues related to security issues in production

This includes content such as:

  • CVEs that affect libraries used in production

  • Issues returned from WASA scans

Inspecting our open-source code will show what packages we're using at which versions, which could lead to security issues --- though in terms of good posture, issues indicating a known security issue and tracking our fixing of that issue and subsequent release should generally remain private.


As a rule, postmortems should generally be written privately, to allow the team to focus on documenting the important details of what went wrong, who was involved in resolution, and what systems were touched, without worrying about self-censorship for possible security details or contact information, and to avoid blaming any individuals publicly.

After finishing the postmortem, the postmortem SHOULD be copied to a public repository with names and sensitive technical information stripped out.

Vendor selection process

Gray area. If the VA has been asked by a vendor to evaluate their software, issues and documentation related to that evaluation should likely remain private. However, if the VA has initiated their own evaluation of a given software, those results are less likely to be sensitive.

Confirm specific cases with DSVA.

Documentation of VA systems and architecture

Gray area. This depends heavily on the systems themselves. Try asking around in OCTO-DE #sre Slack channel.

Areas like the VA's network topology, especially regarding the TIC and surrounding systems, are likely to be considered sensitive by VA's networking and security teams.

Internal phone numbers / email addresses

Personal contact information for individuals working on should generally not be public.

Test user information + credentials for lower environments

Credentials should remain private.

JavaScript errors detected

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

If this problem persists, please contact our support.