GLBA Safeguards Rule and impact on compliance programs
What is the rule?
The Safeguards Rule is a key provision of the Gramm-Leach-Bliley Act (GLBA) that requires financial institutions to establish and maintain an information security program to protect the confidentiality, integrity, and availability of customer information.
The GLBA Safeguards Rule went into effect on May 23, 2003, and has been in effect since then. Financial institutions that are subject to the rule were required to comply with its requirements by that date.
The rule includes ongoing obligations for financial institutions to:
Develop and maintain an information security program
Regularly evaluate and adjust the program
Ensure that their employees are trained and aware of their responsibilities under the program
Many of the provisions of the GLBA Safeguards Rule look similar to many other Information Security requirements we see imposed on companies today. However, changes to the Safeguards Rule have made many financial institutions, insurance providers, and their third party service providers confused about where to start; check out the key components of this law below!
Access Controls
Effective access control policies are critical aspects of data privacy and security programs, regardless of organization size. Access controls are measures that limit access to systems, applications, and data. This helps prevent unauthorized access, theft, or misuse of personal information.
Periodic review of access controls is essential to maintaining their effectiveness. Technical controls (or lines of defense) such as firewalls, intrusion detection systems, and antivirus software should be updated and configured appropriately. Physical controls should also be reviewed periodically to make sure they’re working as intended.
To limit access appropriately, organizations should implement a least privilege model, which gives users to minimum access needed to perform their job functions. Finally, all access should be logged and monitored to detect any suspicious activity, and incident response plans should be in place to respond to any potential security threats that occur.
A comprehensive compliance report can go a long way to achieving compliance by scanning your tech environment, identifying your risk, and producing evidence of compliance with access control policies at your enterprise. Contact us today to learn more about our Enumerator Security Tool.
Multi-Factor Authentication (MFA)
MFA is a great first line of defense for protecting information from unauthorized access. The Safeguards Rule makes it abundantly clear that when accessing nonpublic information, MFA should be implemented to ensure the identity of the individual attempting to access the account.
MFA adds an extra layer of security beyond traditional username and password authentication by requiring users to produce an additional form of identity to confirm they are who they say they are. MFA allows companies to add this verification into already automated online processes and systems, removing any human processes needed to validate a user’s identity.
Industry standards and case law will start to set precedent on what is considered an effective MFA method, especially for access to financial accounts. These heavily regulated industries should seriously evaluate their existing authentication experience, and identify areas to gain efficiencies and user experience wins for their enterprise, while tightening up their compliance posture with the GLBA.
We can help you assess and remediate any potential vulnerabilities with your authentication experience; contact us today to learn more.
Asset Inventories
We’ve heard this referenced or alluded to in many different regulations and standards, but the need to have an actively updated catalog of your data and system assets is required to effectively maintain compliance programs needed to monetize on personal data.
Maintaining a comprehensive inventory of data and systems is crucial for maintaining compliance programs. It can be as basic as having a data dictionary to understand what data you collect, and a list of the systems you store it in. But realistically, if you have an enterprise technology infrastructure, you’re probably looking at needing an automated asset inventory.
Without an inventory, organizations may struggle to identify sensitive information or vulnerable systems, leaving them open to security breaches or non-compliance with privacy regulations. By keeping an up-to-date inventory, you can continuously monitor to make sure your data controls have been effectively applied to enterprise assets.
We’ve seen very few large organizations effectively master this concept yet; lots of times, they’re mostly there but need some help getting over the finish line by tightening up documentation, and evangelizing policy and process. If this is something you think you need help with, don’t wait; contact us today to see how we can expedite your journey to a mature compliance program.
Encryption
You can read more about the administrative nightmare a breach of an unencrypted database creates for your organization in one of our blog posts about breach notification laws, but safe to say even a breach of a single customer’s information is not a walk in the park, and will cost you money to manage. It’s important to take the best precaution you can to safeguard information, and properly encrypt it in rest and in transit, where appropriate and feasible, and supplemented with alternative controls where infeasible.
By encrypting data, it is scrambled into an unreadable format, making it difficult for unauthorized users to read the information if it is stolen. It has been debated back and forth whether encryption in transit and at rest is required, but the Safeguards rule updates imply that it will be required for sensitive personal information. Encrypting information helps safeguard personal or sensitive information from falling into the wrong hands. See some examples below of challenges and consequences related to partial or improper encryption of sensitive assets.
Anthem’s stolen customer database not encrypted (healthcare)
Unencrypted laptop theft breach penalty
Secure Applications
Secure development practices for both in-house development and external implementation into your enterprise infrastructure is now paramount to your compliance program success. A system with secure development practices typically exhibits the following characteristics:
Proactive Approach: Instead of being implemented after production go-live, security features are ideated, implemented, and tested throughout the course of the application build. Get your infosec team involved in application development from day 1.
Continuous Testing: Regular testing is performed throughout development, instead of at the end only.
Robust Architecture: The system is designed with security in mind, and with appropriate controls to protect against vulnerabilities.
Clear Documentation: Proactive and reactive controls and processes are documented and available to internal employees.
Regular Updates: The system is alerted to make relevant updates as needed to maintain acceptable level of security posture for the assets within that system.
Access Controls: Access controls are properly implemented and reviewed on this asset to continuously confirm that the system is free of unauthorized access.
Secure Coding: Secure coding practices are followed to minimize risk during production.
None of this matters if you don’t document all the steps you took, and the results of how your testing turned out. It’s critical to maintain documentation throughout the development process so you’re not stuck in a forever loop of trying to track down legacy information.
Change Management
Speaking of documentation, having a change management process to track how changes will impact your security and privacy is required. Your change management process should include, at a minimum:
Assessment: Some form of audit or test to figure out how a change will impact your environment, or cause unnecessary risk or unintended issues
Planning: A plan is developed that outlines the steps required to implement a change, including resources needed and responsibilities
Testing: Changes are tested in non-production environments to ensure there are no unintended consequences
Communication: Process to inform stakeholders of the change, including purpose, potential impact, and any actions they may need to take
Implementation: Change is deployed in a controlled and monitored manner to minimize disruption and ensure it’s successful
Monitoring: Alerts are in place to monitor changes after implementation to ensure it’s working as intended
Destruction of Data
If you haven’t already, it’s time to implement a data destruction policy and schedule. At a minimum, your policy should have the following:
Data Retention: The Company retains records in accordance with the Company’s Record Retention Schedule.
Data Destruction: Once the data retention period has been met, data will be destroyed from all structured databases and file systems, unless the data is subject to a litigation hold.
To implement a schedule and policy, you need to do the following:
Identify the types of records you have, and categorize them based on purpose for use, and value to your organization
Determine the requirements that apply to each type of record (ex. requirement to retain for a certain period of time)
Develop a retention schedule that outlines the periods for each category of record, and purpose for retaining
Establish processes for managing records and access throughout their lifecycle
Communicate policy and schedule to relevant stakeholders
Monitor compliance with policy
This is a huge body of work, especially if you have years of legacy client records to account for in many different technology environments. Contact us today to learn how we can help you solve this issue.
Risk Assessments
We’re going to talk about the importance of documentation again; it’s so important. With the updates to the Safeguards Rule, it’s clear you’ll need to produce evidence of formal risk assessments of sensitive data processing, collection, storage, and destruction practices to regulators and auditors.
Your should evaluate your technology assets for 3 things:
Confidentiality: How secure your asset is from an unauthorized user?
Integrity: How accurate is the data contained within your asset, and the documentation about your asset?
Availability: How secure is your asset from being compromised in a way that makes it unavailable to administrators or end users?
At a minimum, your technology risk assessment should include:
Asset Inventory: Confirm accuracy of IT asset inventory mentioned above, including hardware, software, and data
Threat Identification: Identify potential threats that could occur in your environments and how risky they are to your enterprise (do you have any controls in place to make them less risky)
Risk Analysis: Analyze the inherent and actual risk of each asset, and any remediation activities that need to happen
Monitoring: Setup plans to periodically re-assess assets, either on a schedule, or after remediation activities have occurred
Incident Response Plan
You need to have a formal process documented and tested to handle any type of incident that would result in loss or unauthorized access of data. The most basic plan and policy includes:
Communication plans
Roles and responsibilities (including process administrators/owners)
Incident identification processes
Incident classification guidelines
Escalation procedures
Incident response processes (including reporting and notification procedures)
Documentation requirements throughout the process
These policies also need to be tested in simulated environments on a regular basis with relevant stakeholders.
We have over a decade of experience building and implementing incident response processes and procedures in some of the most heavily regulated industries in the world. Contact us today to learn more about how we can help accelerate your plan.
Vendor Risk Management
Finally, the GLBA Safeguards Rule updates make it clear you need to document and continuously audit the third parties you interact and exchange data with. This means you need a centralized repository to conduct and document initial and periodic due diligence with your third parties. This also means that you need to document why you don’t need to conduct due diligence on a certain third party; for example, you’re not exchanging any personal information with them.
We have extensive experience documenting, strategizing, and integrating processes into organizations for effective management of third parties, also providing senior leadership with extensive reporting and audit capabilities over their third party relationships. If this sounds like something you could use some help with, contact us today to learn more.