Checklist

GLBA Safeguards Rule Data Inventory & Mapping Checklist

Published May 8, 2026

The 2023 amendments to the FTC Safeguards Rule moved many smaller fintechs into scope and tightened the data-inventory and incident-notification requirements. The Rule now requires a documented data inventory of customer information, written risk-assessment outputs that drive the controls, and 30-day notification of certain security events to the FTC. This checklist covers the structured data-side artifacts the Safeguards Rule program lead needs to maintain. The 2024–2025 enforcement actions cited in our reading focus on missing inventories, stale risk assessments, and unencrypted customer data in dev environments.

0 / 19 complete0%

Customer information inventory (§314.4(c)(1))

  • Per-system inventory of customer information

    List every system, application, or storage location that creates, receives, stores, or transmits customer information with the specific data classes present. Includes vendor systems and third-party processors.

    data_inventory[].system, .data_classes[], .processing_purpose, .vendor_owned
  • Data-flow map (where customer information moves)

    Documented data-flow showing how customer information moves between systems, to vendors, and to consumer-facing products. The flow map is what auditors reconcile to actual network and application telemetry.

    data_flow_map.flows[].source, .destination, .data_classes[], .protocol
  • Customer information classification scheme

    Classification scheme distinguishing customer information from other data with the criteria that drive the classification. Confusion here drives in-scope/out-of-scope errors that compound through the program.

    data_classification.scheme, .criteria[]
  • Retention schedule per data class

    Documented retention schedule per data class with the deletion / destruction process and proof-of-execution. Retained-beyond-need data is both a Safeguards finding and a breach-magnitude amplifier.

    retention_schedule[].data_class, .retention_period, .deletion_process

Risk assessment (§314.4(b))

  • Written risk assessment with triennial refresh

    Per §314.4(b)(1), written risk assessment identifying foreseeable internal and external risks to security, confidentiality, and integrity of customer information. Triennial refresh is the explicit minimum.

    risk_assessment.version, .last_completed, .next_due
  • Risk-to-control mapping

    Each identified risk maps to one or more documented controls per §314.4(b)(2). Risks without control mappings are findings; controls not mapped to any risk suggest the assessment is incomplete.

    risk_assessment.risk_to_control_map[]
  • Reassessment trigger events

    Documented trigger events that force re-assessment ahead of the triennial cadence — material change to operations, security incident, new product launch, vendor change. The trigger inventory and the assessment-execution trail must reconcile.

    risk_assessment.trigger_events[], reassessment_log[]

Required safeguards (§314.4(c)(2)–(7))

  • Access-control restrictions and review

    Per §314.4(c)(2), access controls restricting access to customer information to those with business need. Periodic access reviews must be evidenced.

    access_controls.policy, access_reviews[]
  • Encryption-in-transit and at-rest evidence

    Per §314.4(c)(3), encryption of customer information at rest and in transit. Compensating-controls path is allowed but requires QI written approval.

    encryption.at_rest_evidence, encryption.in_transit_evidence, qi_approved_compensating_controls[]
  • Multi-factor authentication for access to customer information

    Per §314.4(c)(5), MFA for any individual accessing any system with customer information. Service-account exceptions require documented compensating controls.

    mfa.coverage_evidence, mfa.exceptions[]
  • Secure disposal of customer information

    Per §314.4(c)(6), secure disposal of customer information no longer needed. Disposal evidence (certificate of destruction, secure-erase log) must be retained.

    disposal.records[]
  • Change management procedures

    Per §314.4(c)(7), procedures for ensuring system changes don't compromise customer information. Change-management trail must include security review for changes touching in-scope systems.

    change_mgmt.security_reviewed_changes[]
  • Activity monitoring and unauthorized-access detection

    Per §314.4(c)(8), monitoring and logging that allows detection of unauthorized access. Log retention and review schedule must be documented.

    monitoring.coverage_map, log_retention_policy, log_review_schedule

Service provider oversight (§314.4(f))

  • Service-provider inventory with data-handled mapping

    Inventory of service providers with the customer information they handle, the contractual safeguards in place, and the period of the most-recent due-diligence review.

    service_providers[].name, .data_classes_handled, .contract_safeguards_section, .last_review_date
  • Periodic service-provider assessment

    Documented periodic assessment of service-provider safeguards. SOC 2 / ISO 27001 reports + targeted questionnaire is the modal pattern.

    service_provider_reviews[].sp_id, .review_date, .findings[], .remediation_status

Incident response & 30-day notification (§314.4(j))

  • Written incident response plan with last-tested date

    Per §314.4(h), written IR plan covering goals, processes, roles, communication, remediation, and post-incident evaluation. Tabletop testing must be evidenced.

    incident_response.plan_version, .last_tested_date
  • FTC notification trigger evaluation

    Per §314.4(j) (effective May 2024), notification to the FTC within 30 days of a notification event involving 500+ consumers. Trigger evaluation must be a documented step in IR.

    incident_response.ftc_trigger_evaluation_step
  • Notification execution trail

    For each FTC-eligible notification event, the notification artifact (form submission, content, FTC acknowledgment). 30-day clock starts at discovery, not at containment.

    ftc_notifications[].event_id, .discovery_date, .filed_date, .ack_received
  • Annual report to board / qualified individual

    Per §314.4(i), annual report to the board (or designated qualified individual) covering the program's status, risk-assessment results, service-provider arrangements, testing results, and material matters. Missing the annual report is a Safeguards finding.

    annual_report.last_delivered, .recipient, .content_outline

Key takeaways

  • The 2023 Safeguards amendments tightened both the inventory and the notification requirements. Triennial risk-assessment refresh and 30-day FTC notification (500+ consumer events) are the explicit clock-driven obligations.
  • Customer information inventory + data-flow map is the artifact auditors reconcile to. Inventories that don't match observed network telemetry are the highest-frequency finding category.
  • Service-provider oversight is a frequent enforcement source. Contractual safeguards alone don't satisfy §314.4(f) — periodic actual assessment is required.
  • MFA coverage for any individual accessing any system with customer information is a hard requirement. Service-account exceptions need documented compensating controls.