Building the Guardrails™: GLBA: Protecting the Trust Your Clients Place in You

How GLBA helps firms protect client information—and build stronger, more resilient organizations.

Your firm holds sensitive information. Account statements. Tax documents. Social Security numbers. Beneficiary designations. The personal financial stories of your clients, trusted to your care. As your firm grows, you hold more of it—and the responsibility to protect it grows with you.

The Gramm-Leach-Bliley Act, passed in 1999, is the foundational law governing how you collect, use, protect, and disclose this information. For decades, it has been a steady compliance obligation. But the regulatory framework has tightened significantly in recent years. For SEC-registered advisers, GLBA requirements are implemented through Regulation S-P. For firms subject to the FTC Safeguards Rule, or for state-registered advisers operating under applicable state requirements, the specifics vary—but the core obligation is the same: establish and maintain an information-security program reasonably designed to protect the confidentiality, integrity, and availability of customer information.

This is practical, not theoretical. It means knowing what data you hold. It means limiting access to only those who need it. It means protecting it against theft, misuse, and loss. It means being ready to detect when something goes wrong, respond quickly, and notify clients if their information is compromised.

For too many firms, GLBA sits on the shelf as a compliance obligation; a policy checklist, a training requirement, something the CCO manages and the rest of the firm ignores. That approach no longer works, if it ever did. A data breach is not a compliance problem you solve with a fine. It is a business crisis. It damages client relationships, invites regulatory scrutiny, and can threaten your firm’s viability. Regulators expect you to treat data protection as an operational priority, not a compliance burden.

The Four Guardrails of Client Data Protection

Building a robust data-protection program means thinking through four practical, overlapping responsibilities.

Know the information you hold. Start simple: inventory your data. Where does client information live? What systems does it move through? Who has access? You need documentation, the data map that answers these questions clearly. This is not about perfect completeness; it is about knowing where your risks are. Classify your data by sensitivity: account statements are sensitive; general blog content is not. This clarity informs everything else.

Protect it based on risk. Not all data requires the same level of protection. Your information security program should be proportional to the sensitivity of what you hold and the threats you face. Encryption, access controls, and multi-factor authentication are important tools—but which ones you need depend on your specific systems and risk profile. A firm that stores account statements on a cloud platform faces different risks than one using a legacy on-premise system. Your program should reflect your reality, not a generic checklist. This is where working with IT professionals, whether in-house or through a managed service provider, becomes essential.

Control your service providers. If you use a cloud vendor, a payroll processor, a marketing automation tool, or any third party that handles customer information, they become part of your data-protection program. Your service-provider agreements must impose obligations to protect customer information and to notify you promptly if they become aware of a breach. You also need reasonable assurance that they are meeting these obligations. Audit reports, security certifications, and direct communication matter.

A vendor’s data breach is your data breach in the eyes of your clients and regulators.

Prepare to respond and notify. A robust program does not assume breaches will not happen. It assumes they might, and it prepares accordingly. You need a written incident-response program reasonably designed to detect, respond to, and recover from unauthorized access to or use of customer information. This means you know who to contact first (your IT team, your vendors, your counsel). You understand how to assess what happened and how many people were affected. You have procedures for containing the incident and preventing further damage. And you have a process for notifying affected customers when required by law. For many firms, this is the weakest link. When a breach is discovered, panic and improvisation take over. A written plan, tested and understood by key staff, prevents that.

The CCO’s Role—Oversight, Not Omniscience

Data protection is a shared responsibility involving senior management, compliance, IT, operations, vendors, and outside specialists. The firm is responsible. Your role as CCO is to oversee the compliance framework and verify that the program works.

Assign ownership. Make it clear who owns each element of the program—who reports on access controls, who manages vendors, who leads incident response. Distributed responsibility is not diffused responsibility.

Ask informed questions. You do not need to be a cybersecurity expert to do this job well. You need to know what a reasonable program looks like and ask whether your firm has it. Your IT leader or managed service provider should be able to explain your encryption approach, your access controls, and how your systems are monitored. If they cannot, that is the problem to fix, not the conversation to avoid.

Obtain evidence. Your vendors should provide evidence that they meet their contractual obligations. Your incident-response plan should be documented. Your data-handling procedures should be written. Policies sitting in people’s heads are not guardrails. They are hopes.

Confirm the program is tested. The best plan is worthless if no one has ever executed it. When has your incident-response team conducted a tabletop exercise? When did you last review access controls to confirm people still have only the access they need? Testing is not optional. It is the difference between a program and a document.

Escalate unresolved concerns. If your IT team says a control cannot be implemented, or your vendor says they cannot commit to 72-hour breach notification, or your operations team says training is too much overhead—those are not reasons to accept the gaps. Those are reasons for an escalation. Your job is not to solve them. Your job is to make sure someone does.

Turning Policy Into Practice

A written policy is the starting point, not the finish line. The real guardrail is what your firm does every day to keep your program operational and current.

Conduct periodic risk assessments. At least annually, step back and ask: What information do we hold now? What systems does it move through? What are the threats? Have we added vendors, changed platforms, or hired new staff? Have regulations changed? A risk assessment is not a document you file and forget. It is a conversation that informs what you do next.

Review access controls. Who has access to what information? Does a junior advisor still need administrative access to email after they left your firm? Did you ever revoke a former vendor’s login credentials? Access creep is invisible until it is the subject of an audit. Document who has access, review it at least annually, and correct the gaps.

Train your team. New employees need to understand where the lines are. Existing staff need refreshers when policies change or when new tools come online. Training is not a checkbox. It is the mechanism that turns policy into behavior.

Test your incident-response plan. Conduct a tabletop exercise at least once per year. Walk through a scenario: a ransomware attack, a phishing breach, a vendor compromise. Who do you call first? What information do you need? How long does assessment take? Testing reveals gaps in knowledge and responsibility. A tested plan is a plan people understand.

Review vendor contracts and due diligence. When you onboard a new vendor, conduct due diligence and document it. When you renew a contract, review it. Are the data-protection and breach-notification terms still current? Are audit reports current? A vendor agreement drafted three years ago may not reflect the current regulatory landscape. Refresh it.

Document testing and corrective action. When you conduct a risk assessment and find a gap, document it. When you fix it, document that too. When you test your incident-response plan and discover that no one knows how to contact your outside counsel, document the fix and confirm it is done. Documentation is not busy work. It is evidence that your program operates and improves.

Update procedures when things change. When you hire new staff, change vendors, adopt new systems, or discover new risks, update your procedures. Every growing firm reaches a point where memory and informal practices are no longer reliable. Documentation becomes the guardrail that keeps responsibilities clear and processes consistent as the organization changes.

Where Most Firms Stand Now

Compliance with GLBA requirements is now, not future. Some firms have completed their work, they have documented their incident-response programs, reviewed and updated service-provider agreements, and conducted meaningful risk assessments. Others are mid-implementation, working through vendor contracts or finalizing policies. And some are still in the initial stages, having recognized recently that they need to build or strengthen their program.

Wherever your firm is in that spectrum, the priority is the same: completion. If your incident-response plan is still in draft, finalize it and train your team. If your service-provider agreements have not been reviewed for current breach-notification requirements, schedule that work now. If you have not documented your current risk assessment or the controls that address those risks, that is the logical starting point. Regulators are already examining how firms are implementing GLBA. The firms that move deliberately and methodically, establishing clear ownership and realistic timelines, will have less work to do in an audit than those that leave gaps.

More broadly, this is a reminder that the regulatory landscape will keep shifting. New technologies will emerge. New risks will appear. The firms that have built guardrails, not as a one-time compliance exercise, but as an ongoing discipline, will adapt more quickly and more confidently. A firm with clear governance, documented procedures, distributed ownership, and a habit of regular review can absorb regulatory change without panic. That is what separates the firms that treat compliance as a burden from the firms that treat it as a foundation.

Governance is not measured by the policies sitting in a binder. It is measured by how your firm protects client information every day.

Clients may never see your incident-response plan. They may never ask about your vendor due diligence or access controls. They simply trust that you have done the work.

Protecting that trust is not only a compliance obligation. It is one of the guardrails that allows a firm to grow with confidence.

That is what Building the Guardrails™ is about.

This article is part of our ongoing Building the Guardrails™ series, where we explore the governance principles that help financial firms build stronger, more resilient organizations.

Continue the Building the Guardrails™ Series

Part 1: What Is Governance, and Why Should I Care?

Part 2: AI Governance for Modern Firms

Part 3: Protecting Client Information (Current Article)