Contents
PurposeOrganizations can use Ardoq to address U.S. Gramm-Leach-Bliley Act (GLBA) regulatory requirements through this implementation guide. We've designed this pattern to leverage concepts from Regulatory Compliance guidance while extending support for your specific needs. We call this a pattern because companies use different Ardoq metamodels, and we provide a logical, step-by-step approach you can tailor to your implementation. While not required, this guide references the Compliance Assurance solution. You can extend it further using Ardoq's Application Risk Management solution to address other Governance, Risk, and Compliance areas. This guide helps you implement relationships between:
GLBA compliance requires organizations—particularly financial institutions—to implement safeguards for customer financial information. Ardoq enables enterprises to model regulatory requirements and connect them to Policies, Principles, Standards, and Frameworks, establishing links across broader controls and enterprise architecture. This guide uses the Regulatory Compliance Metamodel to help organizations model relationships between requirements and frameworks (NIST/ISO/etc.), controls, internal policies, and assess capabilities, applications, and other relevant components. GLBA requires organizations to understand how business capabilities, applications, processes, and data flows intersect with risk and compliance. This guide addresses key considerations and recommendations for modeling Gramm-Leach-Bliley Act requirements and their relationships to other enterprise architecture parts to maximize Ardoq's value:
| Before you begin Familiarize yourself with:
In addition, familiarize yourself with the Business Capability Realization and Application Lifecycle Management guides. They provide additional information to assist you with modelling regulatory frameworks.
|
How to Model Support for GLBA in Ardoq
GLBA presents regulatory requirements that protect consumer financial data. Modeling these requirements in Ardoq involves representing relationships across enterprise components—from capabilities and controls to third-party services.
The Challenge
Enterprise models become inherently complex due to intricate legislation and regulatory frameworks. GLBA regulation imposes requirements that demand continuous assessments across various enterprise components. Additionally, you can address some GLBA regulatory requirements by implementing standards or frameworks such as NIST or ISO 27001, which adds modeling complexity.
However, this complexity serves an important purpose: frameworks, when integrated with internal controls and policies, provide governance over applications and their underlying technologies, supporting your organization's efforts to adhere to GLBA regulation.
Our Solution
To streamline compliance efforts, model regulations and their respective requirements into unified workspaces alongside other relevant regulatory frameworks. This approach ensures that various regulatory requirements and their assessments can evaluate different business architecture aspects, including capabilities and third-party organizations, rather than just the application portfolio.
Implementation Approach:
Model relationships between GLBA requirements and internal controls, frameworks, or standards to demonstrate compliance
Create a single assessment workspace to evaluate GLBA criticality on Business Capabilities
Assess applications that enable GLBA-critical capabilities
Assess vendors and third parties that support GLBA-relevant applications
Model processes related to GLBA, even when Ardoq isn't the primary application
The Result
Organizations use Ardoq to take a structured approach to addressing GLBA and other regulatory requirements. This method provides a comprehensive view of regulatory impacts on enterprise architecture, improving compliance and risk management. Enterprises can identify gaps and optimize systems, enabling better regulatory requirement handling.
See Also
Identify and assess compliance framework requirements through Ardoq's Compliance Assurance solution
Perform Application Risk Management within Ardoq using the Application Risk Management Purpose, Scope, and Rationale guide
Putting the Guidance into Practice
Modeling GLBA in Ardoq extends both the Compliance Assurance and Application Risk Management solutions by including a regulation-based requirement and, optionally, an assessment component.
The assessment component allows architects and risk stakeholders to conduct business impact assessments across various enterprise architecture components. Learn more in the Architecture Records Purpose, Scope, and Rationale document.
To implement this effectively, create several workspaces and follow these steps:
Step 1: Modeling The Regulation Workspace & Its Requirements
Build regulatory requirements for GLBA using concepts from the Compliance Assurance and Application Risk Management solutions.
Regulation Workspace Components:
Category - Organize a categorized hierarchy according to respective regulations (GLBA, EU AI ACT, NIS2, etc.). Create arbitrary depth with leaf nodes as the component type organized in the hierarchy. The category itself represents the GLBA Regulatory Framework.
Information Artifact - Represents the GLBA Regulatory Framework.
Requirement - Represents specific requirements from the Regulation (e.g., GLBA requires "Ensure the testing program covers all critical systems, applications, and processes, including third-party services").
Step 2: Addressing Regulations through Controls or Standards
Next, create the Control Workspace (Control Library). Before implementing GLBA regulation, organizations often implement standard compliance or control frameworks such as PCI, NIST, or ISO27001 relevant to their business. These frameworks deploy control requirements into organizations to satisfy GLBA regulation requirements.
Modeling Approach:
Establish an 'Is Realized By' relationship from GLBA regulation requirements to relevant control framework requirements. This allows organizations to report on GLBA compliance through control framework control realization.
The diagram shows the relationship between a GLBA requirement and the respective NIST requirement.
For more information about implementing Control Frameworks and controls, see guidance in the Regulation Compliance Metamodel and the Compliance Assurance Metamodel.
Step 3: Establishing GLBA Criticality - Assessment Workspace
Centralize Capability Assessments
When evaluating GLBA criticality for different business functions (Business Capabilities, Applications, etc.), perform these assessments within a single, dedicated Assessment Workspace in Ardoq.
Capability Assessment Steps:
Create assessments for Capabilities (and other components) in an "Assessment" workspace
Make relevant component types 'SUBJECT OF' the respective assessment, modeling assessments as 1:1 relationships between assessment and subject component
Use field values on the subject component type to identify capabilities that handle financial/PII data. For GLBA, add a GLBA criticality field to the Business Capability component so you can easily identify and investigate all capabilities subject to GLBA regulation
Connect the Regulations Workspace (GLBA) and Assessments Workspace through the "Is Realized By" reference type
For more assessment creation guidance, refer to the Architecture Records Metamodel.
Centralize Application Assessments
After identifying business capabilities vital for GLBA compliance, assess the software applications these critical capabilities depend on.
GLBA requires organizations to understand which systems store or process customer data and how those applications are secured.
Application Assessment Steps:
Create assessments for relevant Applications in the "Assessment" workspace
Make relevant component types 'SUBJECT OF' the respective assessment, modeling assessments as 1:1 relationships between assessment and subject component
Add a GLBA criticality field to the application component so you can easily identify and investigate all applications that enable GLBA Critical Capabilities
Use additional field values on the application component type to identify:
Financial Data Type
Customer data collected
Data residence location
System data flows
Evaluate Vendors and Third Parties for Critical Applications
After identifying GLBA-critical capabilities, assess external vendors and third-party organizations that provide or support GLBA-relevant applications these capabilities use.
GLBA requires organizations to understand which vendors can access customer data and whether contractual or technical safeguards ensure financial/personally identifiable data integrity, confidentiality, and availability.
Vendor and Third-Party Assessment Steps:
Use the External Organizations workspace to record third-party supplier organizations using the organization component type
Create assessments for relevant third-party organizations in the "Assessment" workspace
Make relevant component types 'SUBJECT OF' the respective assessment, modeling assessments as 1:1 relationships between assessment and subject component
Use field values on the subject component type to identify regulation applicability and other relevant data such as Financial Data Type. For GLBA, add a GLBA criticality field to the Organization component so you can easily identify and investigate all third-party organizations enabling GLBA Critical Capabilities
Capture key vendor data in Organization Component fields, including GLBA Criticality and required relevant data
Model GLBA-Related Processes
Map or outline business processes related to GLBA in Ardoq to meet compliance demands, even if Ardoq isn't your company's main detailed process modeling tool.
GLBA processes largely realize GLBA requirements. For example, GLBA requires organizations to implement incident reporting processes to notify external regulators or compliance agencies during major incidents. You can easily model the process, including all activities, deliverables, and key responsible people, in Ardoq.