Security Data Lake

SDL stores two categories of data: Non-PII data and PII data

Non-PII Data:
SDL collects and stores structured, semi-structured, and unstructured logs, telemetry, event, and related security monitoring data from sources and tools relevant to CMS’s security posture. This data does not include user information or Personally Identifiable Information (PII). Examples include:

System Vulnerability Data

System Inventory Data (hardware, cloud, and software assets)

Information Security Related Event Data

System Configuration Settings Data

PII Data:
SDL stores limited user information required to support user authentication and access to the system.This PII gets into SDL via CMS IDM (Identity Management) system integration, users do not input PII in SDL directly. SDL integrates with CMS IDM for user authentication. PII collated only includes below 3 data points: This includes:

Full Name

CMS Email Address

CMS User ID, also known as the Enterprise User Administration (EUA) ID, which is a unique 4-character alphanumeric identifier

SDL stores two categories of data:

Non-PII Data:
SDL collects and stores structured, semi-structured, and unstructured logs, telemetry, event, and related security monitoring data from sources and tools relevant to CMS’s security posture. This data does not include user information or Personally Identifiable Information (PII). Examples include:

System Vulnerability Data
System Inventory Data (hardware, cloud, and software assets)
Information Security Related Event Data, including hardware/software logs, alerts, events, Indicators of Compromise (IoC), and Infrastructure as Code (IaC)
System Configuration Settings Data

PII Data:
SDL stores limited user information required to support user authentication and access to the system. This PII gets into SDL via CMS IDM (Identity Management) system integration, users do not input PII in SDL directly. SDL integrates with CMS IDM for user authentication. PII collated only includes below 3 data points:

Full Name
CMS Email Address
CMS User ID, also known as the Enterprise User Administration (EUA) ID, which is a unique 4-character alphanumeric identifier
IoC stands for Indicators of Compromise, and IaC stands for Infrastructure as Code.

• Name
• E-Mail Address
• Other - EUA ID

• Employees
• Vendors/Suppliers/Contractors

• Other - Not Applicable

• Within the OPDIV

• Administrators: To grant and maintain access.

Annual Information System Security & Privacy Awareness (ISSPA) training is mandatory for all personnel who have access to Personally Identifiable Information (PII), including but not limited to the System Owner, System Developer Maintainer, CBT Admin Team, and Database Administrator.

The training covers topics required to protect sensitive data and ensure compliance with CMS Information System Security and Privacy policies. These responsibilities align with NARA's General Records Schedules (GRS), including:

GRS 3.1 – Information Access and Protection Records, which governs records related to information access controls, user permissions, and awareness of access responsibilities; and 

GRS 3.2 – Information Systems Security Records, which includes records related to cybersecurity training, system security planning, incident response, and ongoing security awareness activities.

All personnel must complete this training annually as part of CMS's continuous compliance efforts with FISMA and HHS security and privacy requirements.

CMS follows the requirements listed in the National Archives and Records Administration (NARA) policy, specifically Chapter 8 – Information Technology, Subchapter: Information Technology Security.

While earlier practices referenced GRS 20 and GRS 24, these have since been retired. CMS now complies with the updated General Records Schedules, including:

GRS 3.1 – General Technology Management Records

GRS 3.2 – Information Systems Security Records

GRS 5.2 – Transitory and Intermediary Records

These schedules provide the current federal guidelines for the retention and destruction of electronic records containing Personally Identifiable Information (PII), which CMS follows in conjunction with internal policies to ensure secure data lifecycle management.

PII within SDL is secured using administrative, technical, and physical controls in accordance with CMS and HHS security requirements.

Administrative: Access to PII is restricted to authorized SDL administrators based on Role-Based Access Controls (RBAC) and least privilege principles. CMS policies and procedures governing security, privacy, contingency planning, and incident response are enforced. System administrators are responsible for maintaining compliance documentation, including System Security Plans (SSP), Risk Assessments, and Privacy Impact Assessments (PIA). Security and privacy training is required for authorized personnel.

Technical: User authentication is managed through the CMS Identity Management system utilizing Multi-Factor Authentication (MFA). Access to PII is limited through RBAC. Data at rest is encrypted using AES-256 encryption, and data in transit is encrypted using TLS 1.2 or higher. System logging, monitoring, vulnerability management, and audit capabilities are implemented to support security operations and detect unauthorized access.

Physical: SDL infrastructure is hosted within CMS-approved secure data center environments that implement physical security protections, including badge-controlled facility access, security personnel, environmental protections, emergency power, fire suppression systems, and monitored access to facilities. Physical access is limited to authorized personnel only.