Introduction: The GLBA Safeguards Rule in Context
The Gramm-Leach-Bliley Act (GLBA), enacted in 1999, is the cornerstone United States federal statute governing how financial institutions collect, protect and disclose the non-public personal information (NPI) of their customers. Within GLBA, three principal rules govern data protection: the Financial Privacy Rule (regulating the collection and disclosure of NPI), the Pretexting Provisions (prohibiting the fraudulent acquisition of financial information), and the Safeguards Rule (mandating an information security programme). This guide focuses on the Safeguards Rule as administered and enforced by the US Federal Trade Commission (FTC) under 16 CFR Part 314, together with the substantially revised requirements that took effect in 2022 and 2023.
The Safeguards Rule was fundamentally overhauled by the FTC's Final Rule published on 9 December 2021, which introduced prescriptive, technical security requirements modelled loosely on the New York Department of Financial Services (NYDFS) 23 NYCRR 500 regulation. The original 2003 Rule was principles-based and short; the 2021 amendments transformed it into a detailed control framework. Most substantive provisions became enforceable on 9 June 2023 (originally 9 December 2022, extended by six months). A further amendment effective 13 May 2024 added a breach notification obligation requiring covered financial institutions to notify the FTC of certain security events. This guide reflects the Rule as currently in force in 2026.
Regulatory source and originality note
The GLBA Safeguards Rule is US federal law and regulation (15 U.S.C. 6801-6809; 16 CFR Part 314) and is in the public domain. This guide is original interpretive and audit guidance authored by CyberSigma and does not reproduce copyrighted third-party text. Regulatory citations, section identifiers, dates and thresholds are stated for reference; always confirm current obligations against the Code of Federal Regulations and FTC guidance, as enforcement positions evolve. This guide is not legal advice.
What is the GLBA Safeguards Rule
The Safeguards Rule requires every covered financial institution to develop, implement and maintain a comprehensive written information security programme (WISP) containing administrative, technical and physical safeguards appropriate to the institution's size and complexity, the nature and scope of its activities, and the sensitivity of the customer information it handles. The programme's objectives, as stated in 16 CFR 314.3(b), are threefold: (1) to ensure the security and confidentiality of customer information; (2) to protect against anticipated threats or hazards to the security or integrity of that information; and (3) to protect against unauthorised access to or use of customer information that could result in substantial harm or inconvenience to any customer.
The 2021 amendments introduced nine specific elements that the information security programme must contain (16 CFR 314.4(a)-(i)), moving the Rule from a flexible standard to a set of enumerated, auditable obligations. These include the appointment of a Qualified Individual, a written risk assessment, eight categories of designed safeguards (access controls, data inventory, encryption, secure development, multi-factor authentication, secure disposal, change management, and activity monitoring), continuous monitoring or penetration testing plus vulnerability assessments, personnel training, oversight of service providers, periodic programme evaluation, a written incident response plan, and an annual written report to the board or governing body.
Critically, the Rule applies not only to a financial institution's direct 'customers' but to 'customer information' broadly defined, including information the institution receives about the customers of other financial institutions. Non-public personal information encompasses any personally identifiable financial information that a financial institution collects and that is not publicly available.
| Attribute | Detail |
|---|---|
| Statutory basis | Gramm-Leach-Bliley Act 1999; 15 U.S.C. 6801-6809 |
| Regulation | 16 CFR Part 314 (FTC Standards for Safeguarding Customer Information) |
| Enforcing agency | US Federal Trade Commission (FTC) |
| Region / jurisdiction | United States |
| Original rule effective | 23 May 2003 |
| Amended final rule published | 9 December 2021 |
| Substantive compliance deadline | 9 June 2023 (extended from 9 December 2022) |
| Breach notification amendment effective | 13 May 2024 |
| Companion rules | Financial Privacy Rule (16 CFR Part 313 / Regulation P); Pretexting Provisions |
| Core deliverable | Written Information Security Programme (WISP) |
Who Must Comply: Scope of Applicability
The Safeguards Rule applies to 'financial institutions' over which the FTC has jurisdiction under GLBA. Crucially, the GLBA definition of 'financial institution' is far broader than the everyday meaning: it captures any business significantly engaged in providing financial products or services to consumers. Banks, credit unions and other depository institutions supervised by federal banking regulators (OCC, FDIC, NCUA, Federal Reserve) are subject to those agencies' parallel safeguards standards rather than the FTC Rule, but a very large population of non-bank entities falls squarely under the FTC's version.
The 2021 amendments expanded the definition to include 'finders' (businesses that bring together buyers and sellers of a product or service). A widely discussed consequence is that higher-education institutions administering Title IV federal student aid are treated as financial institutions and must comply, a point reinforced by the US Department of Education.
| Category | Examples of covered entities |
|---|---|
| Lending | Mortgage lenders, mortgage brokers, payday lenders, personal-property and real-estate appraisers, finance companies, motor-vehicle dealers extending or arranging credit |
| Payments and transfers | Cheque cashers, wire transferors, money-services businesses, non-bank payment processors |
| Investment and advisory | Investment advisers not registered with the SEC, certain financial planners |
| Tax and accounting | Tax preparation firms, accountants providing financial services |
| Collections and servicing | Debt collectors, account servicers, loan servicers |
| Intermediaries | 'Finders' bringing together buyers and sellers, credit counsellors, retailers issuing their own credit cards |
| Education | Higher-education institutions participating in Title IV federal student aid programmes |
| Data and CRA-adjacent | Credit reporting resellers, mortgage servicers handling NPI |
The small-business partial exemption
Institutions that maintain customer information concerning fewer than 5,000 consumers are exempt from four specific requirements: the written risk assessment (314.4(b)(1)), the continuous monitoring / penetration testing and vulnerability assessment obligations (314.4(d)(2)), the written incident response plan (314.4(h)), and the annual written report to the board (314.4(i)). All other obligations, including appointing a Qualified Individual and implementing the eight safeguards, still apply. This threshold is counted across the institution's total customer records, not per system.
Entities excluded from the FTC Rule
- Banks, savings associations and credit unions regulated by federal banking agencies (subject to the interagency Guidelines under 12 CFR, not the FTC Rule).
- Institutions regulated by the SEC or CFTC (e.g. broker-dealers, SEC-registered investment advisers) which fall under Regulation S-P and related regimes.
- Insurance companies, which are primarily regulated by state insurance authorities (often adopting the NAIC Insurance Data Security Model Law).
- Entities that are not 'significantly engaged' in providing financial products or services.
Structure of the GLBA Safeguards Rule
The operative structure of the Rule sits in 16 CFR 314.4, which enumerates the elements of the information security programme, supported by definitions in 314.2, the standard for safeguarding in 314.3, the exemptions in 314.6, and the breach notification requirement in 314.5. The following table maps the regulatory sections to the nine programme elements plus supporting provisions.
| CFR section | Programme element / provision | Summary of obligation |
|---|---|---|
| 314.2 | Definitions | Defines customer information, financial institution, information system, security event, Qualified Individual, service provider, encryption, MFA, penetration testing |
| 314.3 | Standard for safeguarding customer information | States the three security objectives and the requirement for a written, comprehensive programme |
| 314.4(a) | Qualified Individual | Designate a single named individual responsible to implement and supervise the programme |
| 314.4(b) | Risk assessment | Conduct a written risk assessment; establish criteria for evaluating and categorising security risks and system sufficiency |
| 314.4(c) | Design and implement safeguards | Eight sub-safeguards: access controls, data inventory, encryption, secure development, MFA, secure disposal, change management, activity monitoring |
| 314.4(d) | Regular testing and monitoring | Continuous monitoring OR annual penetration testing plus biannual vulnerability assessments |
| 314.4(e) | Training and personnel | Security awareness training, qualified security personnel, keep personnel current |
| 314.4(f) | Service provider oversight | Select capable providers, contractually require safeguards, periodically assess them |
| 314.4(g) | Programme evaluation and adjustment | Evaluate and adjust the programme in light of testing, changes and threats |
| 314.4(h) | Written incident response plan | Establish a written plan covering seven required components |
| 314.4(i) | Annual report to governing body | Qualified Individual reports at least annually to the board or senior officer |
| 314.5 | Notification of security events | Notify the FTC within 30 days of discovering a notification event affecting 500 or more consumers |
| 314.6 | Exceptions | Partial exemption for institutions maintaining information on fewer than 5,000 consumers |
Master Assessment Checklist
This is the core auditor-grade section. It enumerates every element of 16 CFR 314.4 and the supporting provisions, with the specific verification objectives and the evidence an assessor should collect. Each h3 corresponds to a regulatory sub-element; nothing is skipped. Use these tables directly as your fieldwork programme.
314.4(a) Qualified Individual
| What to verify | Typical evidence |
|---|---|
| A single Qualified Individual has been formally designated in writing to oversee, implement and enforce the WISP | Appointment letter, org chart, job description, board minutes naming the individual |
| Where the role is performed by an affiliate or service provider, the institution retains responsibility and designates a senior member of personnel to direct and oversee | Service agreement, RACI matrix, internal oversight designation memo |
| The Qualified Individual has appropriate authority, resources and reporting lines to the governing body | Reporting-line documentation, budget approvals, escalation procedures |
| The individual possesses adequate qualifications commensurate with programme complexity | CV, certifications (CISSP, CISM), continuing education records |
314.4(b) Risk Assessment
| What to verify | Typical evidence |
|---|---|
| A written risk assessment has been performed and is periodically refreshed | Dated risk assessment report, revision history, sign-off |
| Criteria are documented for the evaluation and categorisation of identified security risks and threats (internal and external) | Risk scoring methodology, risk register with likelihood/impact ratings |
| Criteria are documented for assessing the confidentiality, integrity and availability of information systems and customer information, including adequacy of existing controls | Control adequacy assessment, CIA impact matrix |
| The assessment describes how identified risks will be mitigated or accepted and how the programme addresses them | Risk treatment plan, mapping of risks to safeguards, residual-risk acceptance records |
| Risk assessment is reperformed on material changes to operations, systems or threat environment | Change-triggered reassessment logs, threat-intelligence review notes |
314.4(c)(1) Access Controls
| What to verify | Typical evidence |
|---|---|
| Technical and physical access controls authenticate and permit access only to authorised users | IAM policy, role definitions, badge/access logs |
| Access to customer information is limited to those with a legitimate business need (least privilege) | Access review reports, entitlement matrices, joiner-mover-leaver records |
| Periodic access recertification is performed and excess privileges revoked | Quarterly access review sign-offs, deprovisioning tickets |
314.4(c)(2) Data Inventory and Mapping
| What to verify | Typical evidence |
|---|---|
| The institution identifies and manages the data, personnel, devices, systems and facilities that enable it to achieve business purposes, in accordance with their relative importance and risk strategy | Data inventory register, asset inventory, system catalogue |
| Customer information flows are mapped across collection, processing, storage, transmission and disposal | Data-flow diagrams, records of processing, network diagrams |
| The inventory is kept current as systems and data change | Inventory update logs, CMDB change records |
314.4(c)(3) Encryption
| What to verify | Typical evidence |
|---|---|
| Customer information is encrypted both at rest and in transit over external networks | Encryption standard, TLS configuration, disk/database encryption evidence |
| Where encryption of information at rest is infeasible, the Qualified Individual has approved compensating controls in writing | Written infeasibility determination, compensating-control approval by Qualified Individual |
| Key management practices protect cryptographic keys throughout their lifecycle | Key management policy, HSM/KMS configuration, key rotation logs |
314.4(c)(4) Secure Development Practices
| What to verify | Typical evidence |
|---|---|
| Secure development practices are adopted for in-house developed applications used to transmit, access or store customer information | SDLC policy, secure coding standards, code review records |
| Procedures exist for evaluating, assessing or testing the security of externally developed applications | Third-party application security assessments, SBOM review, vendor attestations |
314.4(c)(5) Multi-Factor Authentication
| What to verify | Typical evidence |
|---|---|
| MFA is implemented for any individual accessing any information system, unless the Qualified Individual has approved in writing the use of reasonably equivalent or more secure controls | MFA configuration, coverage report, IdP policy |
| MFA uses at least two of: knowledge factor, possession factor, inherence factor | Authentication factor documentation, MFA method inventory |
| Any equivalent-control exception is documented and approved in writing by the Qualified Individual | Written exception approval, compensating-control description |
314.4(c)(6) Secure Disposal
| What to verify | Typical evidence |
|---|---|
| Customer information is securely disposed of no later than two years after the last date it was used in connection with providing a product or service, unless retention is otherwise required or disposal is not reasonably feasible | Data retention and disposal policy, disposal logs, destruction certificates |
| Periodic reviews of data retention are conducted to minimise unnecessary retention | Retention review records, data-minimisation reports |
| Disposal methods render information unreadable/unrecoverable (media sanitisation) | Sanitisation procedures, certificates of destruction, wipe logs |
314.4(c)(7) Change Management
| What to verify | Typical evidence |
|---|---|
| Change management procedures govern modifications to information systems | Change management policy, change tickets, CAB minutes |
| Security impact is assessed as part of change approval | Change risk assessments, approval records |
314.4(c)(8) Monitoring of Authorised Users / Activity Logging
| What to verify | Typical evidence |
|---|---|
| Controls monitor and log the activity of authorised users and detect unauthorised access, use of, or tampering with customer information | SIEM logs, audit trail configuration, alerting rules |
| Logging covers privileged and sensitive-data access | Privileged-access logs, DLP alerts, log-retention settings |
314.4(d) Regular Testing and Monitoring of Safeguards
| What to verify | Typical evidence |
|---|---|
| Continuous monitoring is in place OR, absent it, annual penetration testing is performed | Continuous-monitoring tooling evidence OR annual penetration test report |
| Vulnerability assessments (including system-wide scans) are performed at least every six months and whenever there are material changes or new threats | Biannual vulnerability scan reports, remediation tracking, change-triggered scan records |
| Penetration testing scope reflects the risk assessment and covers systems handling customer information | Penetration test scope, rules of engagement, findings and remediation |
314.4(e) Personnel: Training and Security Staff
| What to verify | Typical evidence |
|---|---|
| Security awareness training is provided to all personnel and updated to reflect risks identified in the risk assessment | Training records, completion rates, curriculum with dates |
| Qualified information security personnel (employees, affiliate or service provider) are utilised to manage risks and perform or oversee the programme | Staffing plan, provider contract, personnel qualifications |
| Security personnel are provided sufficient training and updates to address relevant security risks and are verified to maintain current knowledge | Continuing-education records, threat briefings, certification renewals |
314.4(f) Oversight of Service Providers
| What to verify | Typical evidence |
|---|---|
| Service providers are selected and retained based on their capability to maintain appropriate safeguards | Vendor due-diligence records, security questionnaires, SOC 2 reports |
| Contracts require service providers to implement and maintain safeguards | Executed contracts with security clauses, DPAs |
| Providers are periodically assessed based on the risk they present and the continued adequacy of their safeguards | Ongoing monitoring records, reassessment reports, right-to-audit exercises |
314.4(g) Programme Evaluation and Adjustment
| What to verify | Typical evidence |
|---|---|
| The programme is evaluated and adjusted in light of testing and monitoring results | Programme review minutes, updated WISP versions |
| Adjustments respond to material changes in operations, business arrangements, and results of risk assessments | Change logs tied to programme updates, post-incident revisions |
314.4(h) Written Incident Response Plan
| What to verify | Typical evidence |
|---|---|
| A written incident response plan exists to respond to and recover from any security event materially affecting confidentiality, integrity or availability of customer information | Incident response plan document with version control |
| The plan addresses the goals of the plan | IRP goals statement |
| The plan defines internal processes for responding to a security event | Documented response procedures, playbooks |
| The plan defines roles, responsibilities and levels of decision-making authority | RACI matrix, escalation chart |
| The plan addresses external and internal communications and information sharing | Communications plan, contact lists, regulator/law-enforcement notification procedures |
| The plan identifies requirements for remediation of identified weaknesses in systems and controls | Remediation procedures, corrective action tracking |
| The plan requires documentation and reporting of security events and response activities | Incident logs, after-action report templates |
| The plan mandates post-incident evaluation and revision as necessary | Lessons-learned records, updated plan versions |
314.4(i) Annual Report to the Governing Body
| What to verify | Typical evidence |
|---|---|
| The Qualified Individual reports in writing, at least annually, to the board of directors or equivalent governing body (or a senior officer where none exists) | Annual written security report, board meeting minutes |
| The report addresses the overall status of the programme and compliance with the Rule | Report content covering programme status and compliance |
| The report addresses material matters: risk assessment, risk management/control decisions, service provider arrangements, test results, security events and management responses, and recommendations for change | Report sections evidencing each required topic |
314.5 Notification of Security Events (breach notification)
| What to verify | Typical evidence |
|---|---|
| Procedures exist to notify the FTC as soon as possible and no later than 30 days after discovery of a notification event involving the unauthorised acquisition of unencrypted customer information of 500 or more consumers | Breach notification procedure, FTC notification template |
| The determination of the number of affected consumers and whether encryption keys were also acquired is documented | Impact assessment, forensic report on encryption status |
| Notifications are submitted through the FTC's designated online mechanism with the required content (name/contact, description of event, types of information, date/range, number affected, remediation, whether law enforcement requested delay) | Submitted FTC notification, confirmation receipt |
314.6 Exemption eligibility (fewer than 5,000 consumers)
| What to verify | Typical evidence |
|---|---|
| If claiming the partial exemption, the institution maintains customer information concerning fewer than 5,000 consumers and this is documented | Consumer-count analysis, data inventory count |
| The institution still complies with all non-exempt requirements (Qualified Individual and the eight safeguards) | Evidence of non-exempt controls despite exemption claim |
Scoping, Materiality and Tiering
Although the Safeguards Rule is technically applicable in full to every covered institution above the 5,000-consumer threshold, the Rule is expressly proportional: safeguards must be 'appropriate to the size and complexity' of the institution, the nature and scope of its activities, and the sensitivity of the information. Effective scoping therefore begins with an accurate data inventory and risk assessment that establish the boundary of in-scope systems, data stores and third parties.
- Determine whether the institution is a 'financial institution' under GLBA and whether it falls under FTC jurisdiction (not a bank/SEC/CFTC/insurance-regulated entity).
- Count total consumers whose customer information is maintained to test the fewer-than-5,000 partial exemption.
- Identify all systems that collect, process, store, transmit or dispose of customer information (NPI), including cloud services and SaaS.
- Classify data by sensitivity and map flows to third-party service providers and affiliates.
- Establish materiality thresholds for the incident response plan (events 'materially affecting' CIA) and the 500-consumer / 30-day breach notification trigger.
- Use the risk assessment's categorisation criteria to tier controls by risk, allocating stronger safeguards to higher-risk data and systems.
Materiality of the notification trigger
The 314.5 notification obligation is not triggered by every incident. It applies to a 'notification event': the unauthorised acquisition of unencrypted customer information involving at least 500 consumers. Information is treated as unencrypted if the encryption key was accessed by an unauthorised person. Acquisition is presumed unless the institution has reliable evidence it did not occur. Map these thresholds carefully in your incident response plan.
Implementation Approach (Phased)
CyberSigma recommends a five-phase implementation that maps directly onto the nine programme elements and produces board-ready evidence at each stage.
Phase 1 - Governance and Scoping
- Activities: Confirm applicability and exemption status; designate the Qualified Individual; establish reporting lines to the governing body; define programme charter and policy set.
- Deliverables: Qualified Individual appointment; WISP charter; consumer-count analysis; applicability memo.
Phase 2 - Risk Assessment and Data Inventory
- Activities: Build the data inventory and data-flow maps; perform the written risk assessment with documented categorisation and treatment criteria; identify service providers.
- Deliverables: Data inventory and flow diagrams; written risk assessment; risk register and treatment plan; service provider register.
Phase 3 - Safeguard Design and Implementation
- Activities: Implement the eight 314.4(c) safeguards - access controls, encryption at rest/in transit, MFA, secure development, secure disposal, change management and activity monitoring; document any Qualified-Individual-approved equivalent controls.
- Deliverables: Access control and IAM policies; encryption and key-management standard; MFA coverage report; disposal and retention policy; change management procedure; logging/monitoring configuration.
Phase 4 - Testing, Training and Third-Party Oversight
- Activities: Stand up continuous monitoring or schedule annual penetration tests and biannual vulnerability assessments; roll out security awareness training; establish vendor due diligence, contractual safeguards and periodic reassessment.
- Deliverables: Monitoring/pen-test/vuln-scan schedule and reports; training curriculum and completion records; vendor security clauses and assessment reports.
Phase 5 - Incident Response, Reporting and Continuous Improvement
- Activities: Draft and test the written incident response plan (seven components) including the FTC 30-day/500-consumer notification workflow; produce the annual written report to the governing body; institutionalise programme evaluation and adjustment.
- Deliverables: Incident response plan and tabletop results; FTC notification playbook; annual board report; programme review cadence.
Maturity / Capability Model
The Rule itself does not define maturity levels, but CyberSigma applies a five-level capability model to help institutions benchmark and plan improvement. This aligns the enumerated obligations with observable programme maturity.
| Level | Name | Characteristics against the Safeguards Rule |
|---|---|---|
| 1 | Initial | No formal WISP; no Qualified Individual; ad hoc controls; likely non-compliant |
| 2 | Developing | Qualified Individual named; draft WISP; partial risk assessment; some safeguards but gaps in MFA, encryption or logging |
| 3 | Defined | Full written risk assessment; all eight 314.4(c) safeguards implemented; training and vendor clauses in place; incident response plan drafted |
| 4 | Managed | Continuous monitoring or regular pen tests and biannual scans; metrics tracked; annual board report delivered; vendor reassessments performed; notification workflow tested |
| 5 | Optimised | Programme continuously evaluated and adjusted; automated evidence collection; threat-informed control tuning; integrated with enterprise risk and other frameworks (NYDFS, ISO 27001) |
Assessment and Audit Approach
- Confirm scope and applicability: verify FTC jurisdiction, financial-institution status and the 5,000-consumer exemption position.
- Review governance: confirm the Qualified Individual designation, authority and reporting lines to the governing body.
- Examine the written risk assessment: test that categorisation and treatment criteria exist and that reassessment is triggered by material change.
- Test the eight 314.4(c) safeguards individually against the master checklist, sampling systems handling customer information.
- Evaluate testing and monitoring: confirm continuous monitoring or annual pen testing plus biannual vulnerability assessments, and review remediation.
- Assess personnel and training: verify awareness training coverage and qualification of security staff.
- Review service provider oversight: examine due diligence, contract clauses and periodic reassessments.
- Inspect the incident response plan against the seven required components and test the FTC notification workflow.
- Verify the annual written report to the governing body and its required content.
- Assess programme evaluation and adjustment, then document findings, rate maturity and issue a remediation roadmap.
Evidence Request List
- Governance: Qualified Individual appointment, WISP document, board minutes, reporting-line documentation.
- Risk management: written risk assessment, risk register, categorisation and treatment criteria, reassessment logs.
- Data governance: data inventory, data-flow diagrams, asset/system catalogue, retention and disposal policy, destruction certificates.
- Access and identity: IAM policy, access review reports, least-privilege entitlement matrices, MFA coverage reports, joiner-mover-leaver records.
- Cryptography: encryption standard, TLS configuration, at-rest encryption evidence, key management policy, rotation logs, written infeasibility determinations.
- Development and change: SDLC/secure coding standards, third-party app security assessments, change management tickets and CAB minutes.
- Testing and monitoring: penetration test reports, biannual vulnerability scans, continuous-monitoring tooling evidence, SIEM/log configuration, remediation trackers.
- Personnel: security awareness training records and completion rates, security staff qualifications and continuing education.
- Third parties: vendor due diligence, SOC 2 reports, contracts with security clauses, DPAs, periodic reassessment records.
- Incident response: written incident response plan, tabletop/after-action reports, incident logs, FTC notification templates and submissions.
- Board reporting: annual written report(s) to the governing body evidencing all required topics.
Roles and Responsibilities
| Role | Responsibilities under the Safeguards Rule |
|---|---|
| Board of directors / governing body | Receive at least an annual written report; provide oversight and resourcing; approve programme direction |
| Qualified Individual | Implement, supervise and enforce the WISP; approve equivalent controls in writing; report to the governing body; oversee incident response |
| CISO / security team | Design and operate the eight safeguards, monitoring, testing and training under the Qualified Individual's direction |
| IT operations | Implement access controls, encryption, MFA, change management, logging and secure disposal |
| Data / privacy officer | Maintain data inventory and flows; align with the Financial Privacy Rule and retention/disposal obligations |
| Procurement / vendor management | Conduct due diligence, embed contractual safeguards, perform periodic provider reassessments |
| HR / L&D | Deliver and track security awareness training; support secure joiner-mover-leaver processes |
| Legal / compliance | Advise on FTC notification obligations, thresholds and enforcement exposure; maintain regulatory watch |
| Business unit owners | Own customer information within their processes and support least-privilege access decisions |
KPIs and Metrics to Track
- MFA coverage percentage across all systems accessing customer information (target 100%, with documented exceptions).
- Encryption coverage of customer information at rest and in transit (percentage of in-scope data stores and flows).
- Percentage of customer information disposed within the two-year secure-disposal window.
- Access recertification completion rate and number of excess-privilege revocations per cycle.
- Time to remediate critical and high vulnerabilities from biannual scans and penetration tests.
- Security awareness training completion rate and phishing simulation failure rate.
- Number and percentage of service providers with contractual safeguards and current reassessments.
- Mean time to detect and mean time to respond to security events.
- Number of notification events and adherence to the 30-day FTC notification deadline.
- Percentage of risk-register items with an approved treatment or documented acceptance.
- On-time delivery of the annual written report to the governing body.
Readiness Checklist
- Applicability and exemption status confirmed and documented.
- Qualified Individual formally designated with authority and reporting lines.
- Written, comprehensive information security programme (WISP) approved.
- Written risk assessment completed with categorisation and treatment criteria.
- Data inventory and data-flow maps current and maintained.
- Access controls enforcing least privilege with periodic recertification.
- Encryption of customer information at rest and in transit (or approved equivalents).
- MFA implemented for all system access (or Qualified-Individual-approved equivalents).
- Secure development and third-party application security testing in place.
- Secure disposal within two years and documented retention reviews.
- Change management with security impact assessment operational.
- Activity logging and monitoring of authorised users deployed.
- Continuous monitoring OR annual penetration test plus biannual vulnerability assessments scheduled and performed.
- Security awareness training delivered and qualified security personnel in place.
- Service provider due diligence, contractual safeguards and periodic reassessments completed.
- Written incident response plan covering all seven components and tested.
- FTC notification workflow (30 days / 500 consumers) documented and rehearsed.
- Annual written report delivered to the governing body.
- Programme evaluation and adjustment cadence established.
Common Gaps and Findings
- No formally designated Qualified Individual, or the role lacks authority and board reporting lines.
- Risk assessment is undocumented or lacks the required categorisation and treatment criteria.
- Data inventory is incomplete, so customer information in shadow IT and SaaS escapes the programme.
- MFA is deployed only for remote access, not for all system access, with no written equivalent-control approval.
- Encryption at rest is absent for legacy databases without a documented infeasibility determination.
- Secure disposal is not enforced; customer information is retained far beyond two years with no retention review.
- Vulnerability assessments are not performed every six months, or penetration testing is missing where continuous monitoring is absent.
- Service provider contracts lack security clauses and there is no periodic reassessment.
- The incident response plan omits required components or the FTC 30-day/500-consumer notification workflow.
- No annual written report is delivered to the governing body, or it omits required topics.
- The institution wrongly assumes exemption without documenting the fewer-than-5,000-consumer count.
- Programme is static and never adjusted after tests, incidents or material operational change.
GLBA Safeguards Mapped to Other Frameworks
Institutions rarely operate under a single regime. The following mapping helps assessors reuse evidence and align controls across common frameworks. Mappings are indicative, not one-to-one.
| GLBA Safeguards element | NYDFS 23 NYCRR 500 | NIST CSF 2.0 | ISO/IEC 27001:2022 | PCI DSS v4.0 |
|---|---|---|---|---|
| Qualified Individual (314.4(a)) | CISO (500.4) | Govern (GV.RR) | 5.3 Roles and responsibilities | 12.1 / 12.4 security programme ownership |
| Risk assessment (314.4(b)) | Risk assessment (500.9) | Identify (ID.RA) | 6.1.2 / Clause 6 risk assessment | 12.3 targeted risk analyses |
| Access controls (314.4(c)(1)) | Access privileges (500.7) | Protect (PR.AA) | A.5.15 / A.8.3 access control | 7 restrict access; 8 identify users |
| Data inventory (314.4(c)(2)) | Asset management (500.13) | Identify (ID.AM) | A.5.9 inventory of assets | 9.5 / data flow scoping |
| Encryption (314.4(c)(3)) | Encryption of NPI (500.15) | Protect (PR.DS) | A.8.24 cryptography | 3.5 / 4.2 encryption of CHD |
| MFA (314.4(c)(5)) | MFA (500.12) | Protect (PR.AA) | A.8.5 secure authentication | 8.4 / 8.5 MFA |
| Secure disposal (314.4(c)(6)) | Limitations on data retention (500.13) | Protect (PR.DS) | A.8.10 information deletion | 3.2 / 9.4 data retention and disposal |
| Testing and monitoring (314.4(d)) | Pen testing and vuln assessments (500.5) | Detect (DE.CM) | A.8.8 / A.8.16 monitoring | 11.3 / 11.4 scanning and testing |
| Training (314.4(e)) | Training and monitoring (500.14) | Protect (PR.AT) | A.6.3 awareness | 12.6 security awareness |
| Service provider oversight (314.4(f)) | Third-party providers (500.11) | Govern (GV.SC) | A.5.19 supplier relationships | 12.8 third-party management |
| Incident response (314.4(h)) | Incident response (500.16) | Respond (RS) | A.5.24 incident management | 12.10 incident response |
| Notification of events (314.5) | 72-hour notice (500.17) | Respond (RS.CO) | A.5.24 / A.6.8 reporting | 12.10.6 breach handling |
How CyberSigma helps
CyberSigma is a CERT-In empanelled, PCI QSA advisory partner that takes financial institutions from applicability analysis to audit-ready GLBA Safeguards compliance. We confirm your FTC-jurisdiction and exemption status, appoint or coach your Qualified Individual, build the written risk assessment and data inventory, and design and validate all eight 314.4(c) safeguards including MFA, encryption and secure disposal. Our teams stand up continuous monitoring, penetration testing and biannual vulnerability assessments, harden service-provider oversight, author and rehearse your incident response plan and FTC 30-day/500-consumer notification workflow, and produce the annual board report. Because we map GLBA to NYDFS, NIST CSF, ISO 27001 and PCI DSS, you gain a single evidence base that satisfies multiple regulators. Talk to CyberSigma to make your Safeguards programme provably compliant and continuously improving.
Frequently asked questions
Who is covered by the FTC Safeguards Rule?
Non-bank financial institutions such as mortgage lenders, fintechs, auto dealers and finance companies handling customer financial information.
Official documents
CyberSigma resources
Need help with GLBA Safeguards?
CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.