13.1 Enterprise Architecture & IT Governance Alignment
Key Takeaways
- Enterprise Architecture (EA) frameworks establish structural alignment between corporate strategy and operational technology execution, preventing architectural drift and unmanaged risk.
- TOGAF defines four interconnected architecture domains (BDAT: Business, Data, Application, Technology) executed iteratively through the Architecture Development Method (ADM).
- SABSA provides a business-driven security architecture matrix combining 6 interrogatives with 6 operational layers, establishing verifiable two-way traceability between business drivers and security controls.
- The Zachman Framework functions as an ontological classification taxonomy rather than a step-by-step process, organizing architectural artifacts across 36 distinct stakeholder intersections.
- A healthy Configuration Management Database (CMDB) serves as the definitive single source of truth for Configuration Items (CIs) and dependency mapping, enabling accurate change risk assessment and root-cause analysis.
13.1 Enterprise Architecture & IT Governance Alignment
In modern enterprises, information technology is not merely a utility; it is the primary engine of value delivery, operational execution, and competitive differentiation. However, as organizations adopt hybrid multi-cloud environments, distributed microservices, and legacy integration layers, technology ecosystems frequently suffer from uncontrolled complexity, architectural drift, and shadow IT. When IT infrastructure evolves in ad-hoc silos without strategic alignment, significant operational risks emerge: unpatched legacy dependencies, conflicting identity boundaries, regulatory non-compliance, and catastrophic single points of failure.
To ensure technology investments directly support business goals while remaining within approved risk appetite parameters, organizations implement Enterprise Architecture (EA) frameworks and IT Service Management (ITSM) governance. Aligned with ISACA's Risk IT Framework, COBIT 2019, and the CRISC Body of Knowledge, enterprise architecture provides the formal blueprint that bridges high-level strategic objectives with technical implementations, ensuring that risk management controls are embedded by design across all technology layers.
+-----------------------------------------------------------------------------+
| ENTERPRISE ARCHITECTURE & GOVERNANCE ALIGNMENT |
| |
| +---------------------------------------------------------------------+ |
| | ENTERPRISE BUSINESS STRATEGY | |
| | - Business Goals, Regulatory Mandates, & Board Risk Appetite | |
| +----------------------------------+----------------------------------+ |
| | |
| v GOVERNS & DIRECTS |
| +---------------------------------------------------------------------+ |
| | ENTERPRISE ARCHITECTURE BLUEPRINT | |
| | - TOGAF: Business, Data, Application, Technology (BDAT) | |
| | - SABSA: Business-Driven Security Matrix & Traceability | |
| | - Zachman: 6x6 Perspective & Interrogative Taxonomy Matrix | |
| +----------------------------------+----------------------------------+ |
| | |
| v OPERATIONALIZES |
| +---------------------------------------------------------------------+ |
| | IT SERVICE MANAGEMENT & CONTROL EXECUTION | |
| | - ITIL 4 Service Value System (SVS) & Service Value Chain | |
| | - CMDB Configuration Items (CIs) & Dependency Mapping | |
| | - Change Advisory Board (CAB) & Hardened Configuration Baselines | |
| +---------------------------------------------------------------------+ |
+-----------------------------------------------------------------------------+
1. Enterprise Architecture Frameworks
Enterprise Architecture defines the structure, behavior, and relationships of an organization's business processes, information systems, personnel, and organizational sub-units. From a risk governance perspective, an EA framework ensures that security safeguards, compliance obligations, and resilience requirements are systematically baked into the enterprise rather than retrofitted reactively after deployment.
+-----------------------------------------------------------------------------+
| COMPARISON OF CORE ENTERPRISE ARCHITECTURE FRAMEWORKS |
| |
| Framework Primary Nature Core Focus Key Mechanism |
| --------- ---------------- ------------------------- ------------- |
| TOGAF Process / Method IT & Business Alignment ADM Iterative |
| across 4 Domains (BDAT) Cycle |
| |
| SABSA Security / Risk Business-Driven Security 6x6 Traceable |
| Methodology Architecture Matrix Matrix |
| |
| Zachman Ontology / 2D Classification Scheme 6 Interrogative|
| Taxonomy for Enterprise Artifacts x 6 Persona |
+-----------------------------------------------------------------------------+
A. The Open Group Architecture Framework (TOGAF)
TOGAF is a globally recognized, process-oriented framework for enterprise architecture development. Developed by The Open Group, TOGAF provides a comprehensive methodology and supporting tools for planning, designing, implementing, and governing enterprise IT architecture.
At the core of TOGAF is the Architecture Development Method (ADM), an iterative cycle of continuous architectural design, transition planning, and governance. The ADM organizes enterprise architecture into four foundational domains (frequently referred to as the BDAT stack):
- Business Architecture: Defines the commercial strategy, organizational structure, business models, governance arrangements, and key business processes. It identifies what the business does and why.
- Data (Information) Architecture: Defines the structural organization of physical and logical data assets, data governance models, data management resources, and master data flows across the organization.
- Application Architecture: Defines the blueprint for individual applications to be deployed, their interactions, API contracts, dependencies, and relationships to core business processes.
- Technology Architecture: Defines the physical and virtual hardware, software infrastructure, networks, cloud platforms, and middleware required to support the deployment of business, data, and application services.
+-----------------------------------------------------------------------------+
| THE TOGAF BDAT ARCHITECTURE STACK |
| |
| +---------------------------------------------------------------------+ |
| | [B] BUSINESS ARCHITECTURE: Strategy, Governance, Business Processes | |
| +----------------------------------+----------------------------------+ |
| | |
| v DRIVES DATA REQUIREMENTS |
| +---------------------------------------------------------------------+ |
| | [D] DATA ARCHITECTURE: Data Models, Flows, Schema, Storage, Privacy | |
| +----------------------------------+----------------------------------+ |
| | |
| v INFORMS SOFTWARE BLUEPRINTS |
| +---------------------------------------------------------------------+ |
| | [A] APPLICATION ARCHITECTURE: Systems, APIs, Microservices, ERP | |
| +----------------------------------+----------------------------------+ |
| | |
| v RUNS ON HARDWARE & CLOUD |
| +---------------------------------------------------------------------+ |
| | [T] TECHNOLOGY ARCHITECTURE: Cloud, Compute, SAN, Networks, Firewalls| |
| +---------------------------------------------------------------------+ |
+-----------------------------------------------------------------------------+
B. Sherwood Applied Business Security Architecture (SABSA)
While TOGAF addresses general IT architecture, SABSA is the premier methodology for developing business-driven, risk-aligned enterprise information security architectures. The fundamental tenet of SABSA is that security architecture must not exist to restrict business operations; rather, it exists to enable the business to take calculated risks safely and achieve its commercial objectives.
SABSA utilizes a comprehensive 6x6 matrix that maps six fundamental interrogative questions across six distinct vertical architectural layers (stakeholder perspectives):
-
The Six Interrogatives (Columns):
- What (Assets / Data)
- Why (Motivation / Business Drivers / Risk Appetite)
- How (Functions / Operations / Security Mechanisms)
- Who (People / Roles / Trust Boundaries / Identities)
- Where (Locations / Networks / Cloud Environments)
- When (Time / Sequences / Lifecycles / Incident Response)
-
The Six Architectural Layers (Rows):
- Contextual Security Architecture: Business View (What business problems are we solving? Business risk appetite).
- Conceptual Security Architecture: Architect's View (High-level security principles, fundamental security concepts, trust models).
- Logical Security Architecture: Designer's View (Information security policies, access control models, cryptographic services).
- Physical Security Architecture: Builder's View (Data centers, physical appliances, network segmentation, firewalls, servers).
- Component Security Architecture: Tradesman's / Specialist's View (Specific algorithms, digital certificates, firewall rules, IAM configurations).
- Operational Security Architecture: Facility Manager's / Operations View (Day-to-day administration, patch management, incident response, monitoring).
+-----------------------------------------------------------------------------+
| THE SABSA 6x6 MATRIX STRUCTURE |
| |
| Perspectives / Layers What Why How Who Where When |
| --------------------- ------- ------- ------- ------ ------ ------ |
| 1. Contextual (Business)Assets Goals Process Org Sites Events |
| 2. Conceptual (Architect)Info Risk Trust Roles Domain Time |
| 3. Logical (Designer) Data Rules Services Users Enclave Sched |
| 4. Physical (Builder) DB/Files Policy Controls Groups Subnets Steps |
| 5. Component (Tradesman)Hardware Threats Software PKI/ACL Hosts Clock |
| 6. Operational (Manager)Ops Data Audit SOPs Admins NOC/SOC Shifts |
+-----------------------------------------------------------------------------+
[!IMPORTANT] Two-Way Traceability in SABSA: SABSA establishes mandatory two-way traceability. Top-down traceability proves that every security tool and rule (Component/Physical layer) directly addresses a documented business goal or risk appetite constraint (Contextual layer). Bottom-up traceability allows security teams to justify expenditures to the Board of Directors by demonstrating how a specific technical control protects a core business revenue stream.
C. The Zachman Framework for Enterprise Architecture
Originating from John Zachman in 1987, the Zachman Framework is an enterprise ontology and classification taxonomy. It is critical for CRISC candidates to recognize that Zachman is not a step-by-step methodology or implementation process; it is a structured 2D classification schema for organizing architectural artifacts.
The framework is arranged as a 6x6 matrix intersecting 6 communication interrogatives (What, How, Where, Who, When, Why) with 6 stakeholder perspectives:
- Executive Perspective (Planner / Scope): High-level strategic context.
- Business Management Perspective (Owner / Enterprise Model): Business process definitions.
- Architect Perspective (Designer / System Model): Logical architectural representations.
- Engineer Perspective (Builder / Technology Model): Physical implementations and constraints.
- Technician Perspective (Implementer / Out-of-Context): Granular code, scripts, and components.
- Operational Perspective (Functioning Enterprise): Live operational environment.
2. IT Service Management (ITSM) & ITIL 4 Governance
Enterprise architecture defines the blueprint, but IT Service Management (ITSM) operationalizes technology delivery. ITIL 4 (Information Technology Infrastructure Library) provides the leading framework for managing the complete lifecycle of IT services.
+-----------------------------------------------------------------------------+
| ITIL 4 SERVICE VALUE SYSTEM (SVS) |
| |
| [OPPORTUNITY / DEMAND] |
| | |
| v |
| +---------------------------------------------------------------------+ |
| | ITIL 4 SERVICE VALUE SYSTEM | |
| | |
| | +-------------------------------------------------------------+ |
| | | GUIDING PRINCIPLES | |
| | +-------------------------------------------------------------+ |
| | | GOVERNANCE | |
| | +-------------------------------------------------------------+ |
| | | SERVICE VALUE CHAIN | |
| | | [Plan] -> [Engage] -> [Design & Transition] | |
| | | -> [Obtain/Build] -> [Deliver & Support] | |
| | +-------------------------------------------------------------+ |
| | | PRACTICES | |
| | | (General Mgmt, Service Mgmt, Technical Mgmt) | |
| | +-------------------------------------------------------------+ |
| | | CONTINUAL IMPROVEMENT | |
| | +-------------------------------------------------------------+ |
| +---------------------------------------------------------------------+ |
| | |
| v |
| [CO-CREATED VALUE: PRODUCTS & SERVICES] |
+-----------------------------------------------------------------------------+
Core Elements of the ITIL 4 Service Value System (SVS):
- Guiding Principles: Universal recommendations that guide decision-making under all circumstances (e.g., Focus on Value, Start Where You Are, Progress Iteratively with Feedback, Collaborate and Promote Visibility, Think and Work Holistically, Keep It Simple and Practical, Optimize and Automate).
- Governance: The oversight mechanisms by which the organization is directed and controlled, aligning IT activities with enterprise risk appetite.
- Service Value Chain (SVC): An operating model consisting of six interconnected activities:
- Plan: Ensuring shared understanding of vision, status, and direction.
- Improve: Driving continual enhancement of services, practices, and controls.
- Engage: Interacting with stakeholders to understand needs and transparency.
- Design & Transition: Ensuring services cost-effectively meet stakeholder expectations and security baselines.
- Obtain/Build: Creating or acquiring service components according to architecture specs.
- Deliver & Support: Operating services in production according to agreed SLAs.
- Practices: 34 management practices across General, Service, and Technical domains.
- Continual Improvement: Ongoing alignment of services with changing business risk factors.
Incident Management vs. Problem Management
ITIL deliberately separates the practice that restores service from the practice that removes the cause, and CRISC items routinely punish candidates who collapse the two.
| Practice | Trigger | Objective | Primary Measure | Consequence of Omitting It |
|---|---|---|---|---|
| Incident Management | A user-visible service interruption or degradation | Restore normal service operation as fast as possible, including via a temporary workaround | Mean Time to Restore (MTTR); SLA breach count | Extended outage and availability-impact losses |
| Problem Management | One or more incidents whose underlying cause is unknown | Identify, document, and eliminate the root cause | Repeat-incident rate; known-error closure rate | Chronic incident recurrence; the risk register never reflects the true systemic exposure |
- Reactive problem management investigates the cause of incidents that have already occurred, feeding formal root-cause analysis into corrective action plans.
- Proactive problem management mines incident and event trend telemetry to find latent defects before they cause an outage. This is the ITSM practice that most directly generates new entries for the enterprise risk register.
- A known error is a problem with a documented root cause and a documented workaround, recorded in a Known Error Database (KEDB). A known error that is left open indefinitely is an accepted risk in everything but name: the risk practitioner must ensure it carries a named owner, a compensating control, and a re-evaluation date, exactly as a formal risk acceptance would.
[!TIP] Exam decision rule: if the stem describes a service that is currently down, the correct first action belongs to Incident Management (restore service, even with a workaround). If the stem describes the same failure recurring for the fourth time this quarter, the correct answer belongs to Problem Management (root-cause elimination). Repeatedly closing incidents without raising a problem record is the classic distractor.
3. Configuration Management & Change Governance
Operational instability and security breaches frequently trace back to unmanaged configuration changes and unauthorized drift. Effective IT operations risk management requires rigorous control over Configuration Items and formal change governance.
+-----------------------------------------------------------------------------+
| CMDB RELATIONSHIP & DEPENDENCY MAPPING |
| |
| [BUSINESS SERVICE: ONLINE PAYMENT GATEWAY (PCI DSS SCOPE)] |
| | |
| v DEPENDS ON |
| [APPLICATION CI: Transaction Processing Engine v3.4] |
| | |
| +-----------------+-----------------+ |
| v v |
| [DATABASE CI: Oracle RAC] [SERVER CI: Linux VM (AppHost-01)] |
| | | |
| v HOSTED ON v RUNS ON |
| [SAN STORAGE CI: NetApp LUN] [HYPERVISOR CI: VMware ESXi Host 04] |
| | | |
| +-----------------+-----------------+ |
| v CONNECTED VIA |
| [NETWORK CI: Core Cisco Nexus 9000 Switch (VLAN 102)] |
+-----------------------------------------------------------------------------+
A. Configuration Management Database (CMDB)
A Configuration Management Database (CMDB) is a centralized repository that stores information about hardware, software, systems, facilities, and personnel—known as Configuration Items (CIs)—as well as the critical dependencies and relationships between them.
Risk Management Value of a CMDB:
- Impact & Blast Radius Analysis: Before approving a major change or firewall rule adjustment, administrators query the CMDB to determine which critical business applications will be affected.
- Vulnerability Remediation Prioritization: When a critical zero-day vulnerability is announced (e.g., Log4j), the CMDB allows risk teams to instantly identify every server, application, and business process utilizing the vulnerable software library.
- Asset Visibility & Shadow IT Reduction: Prevents rogue or unmanaged infrastructure from escaping vulnerability management and compliance audits.
[!NOTE] The Stale CMDB Risk: A CMDB is only as valuable as its data accuracy. If discovery tools fail to run or manual changes bypass the CMDB, the repository becomes "stale." Operating with a stale CMDB creates dangerous blind spots during incident response, increases change failure rates, and invalidates risk assessments.
B. Change Management & Change Enablement Workflows
Uncontrolled changes represent one of the leading causes of enterprise outages and security vulnerabilities. Formal change enablement balances operational agility with risk mitigation through structured approval tiers.
+-----------------------------------------------------------------------------+
| STRUCTURED CHANGE CLASSIFICATION WORKFLOW |
| |
| [CHANGE REQUEST SUBMITTED] |
| | |
| +---> [STANDARD CHANGE] |
| | - Low risk, routine, pre-approved, documented SOP |
| | - Action: Automated approval & immediate execution |
| | |
| +---> [NORMAL CHANGE] |
| | - Moderate to high risk, non-routine |
| | - Action: Risk assessment, peer review, CAB approval, |
| | scheduled maintenance window, rollback plan tested |
| | |
| +---> [EMERGENCY CHANGE] |
| - Urgent resolution of major incident or zero-day |
| - Action: Emergency CAB (ECAB) expedited approval, |
| post-implementation review (PIR) mandatory |
+-----------------------------------------------------------------------------+
ITIL Change Categories and Governance Requirements:
| Change Category | Risk Profile | Approval Authority | Governance & Documentation Requirements |
|---|---|---|---|
| Standard Change | Low risk, highly frequent, well-understood | Pre-authorized by policy / automated | Follows established Standard Operating Procedures (SOPs). Logged automatically in CMDB without requiring individual CAB meetings. |
| Normal Change | Moderate to High risk, non-routine | Change Advisory Board (CAB) | Requires formal risk assessment, business impact analysis, technical peer review, rollback/backout script validation, and scheduling during authorized maintenance windows. |
| Emergency Change | Critical risk to business continuity or security | Emergency CAB (ECAB) | Expedited approval process (often CISO/IT Director verbal or SMS sign-off). Mandatory requirement to document the change retroactively and conduct a Post-Implementation Review (PIR) within 48 hours. |
C. Secure Configuration Baselines & Hardening
To prevent security drift and configuration vulnerabilities, enterprises establish standardized secure configuration baselines derived from industry standards such as Center for Internet Security (CIS) Benchmarks and DISA Security Technical Implementation Guides (STIGs).
- Golden Images & Infrastructure as Code (IaC): Virtual machine templates and container images are pre-hardened with baseline security configurations (disabling unnecessary services, enforcing least privilege, setting password policies) and deployed immutably via IaC pipelines.
- Automated Configuration Drift Monitoring: Automated tools (e.g., CSPM, Ansible, Puppet) continuously compare live system configurations against approved baselines. When unauthorized changes are detected, automated alerts fire or self-healing playbooks revert the configuration to the approved state.
4. CRISC Exam Traps & Real-World Scenarios
Exam Trap 1: Confusing Zachman (Taxonomy) with TOGAF (Methodology)
- The Trap: An exam question describes an organization seeking a step-by-step, iterative process to transition IT systems from a baseline architecture to a target architecture, and lists Zachman as an option.
- The Reality: Zachman is a taxonomy/ontology for categorizing artifacts, not a process model. TOGAF's Architecture Development Method (ADM) is the step-by-step process methodology.
Exam Trap 2: Believing Emergency Changes Bypass All Governance
- The Trap: Assuming that during a severe cybersecurity incident, emergency changes do not require documentation, review, or post-implementation sign-off.
- The Reality: Emergency changes bypass full CAB pre-approval via the Emergency CAB (ECAB) to restore service quickly, but mandatory retroactive documentation and Post-Implementation Reviews (PIR) are strictly required to ensure integrity and identify root causes.
Exam Trap 3: Treating the CMDB as a Simple Asset List
- The Trap: Assuming a CMDB is merely a spreadsheet of computer hardware.
- The Reality: The defining characteristic of a CMDB is relationship and dependency mapping between Configuration Items (CIs), which enables risk practitioners to evaluate the business blast radius of outages and changes.
An enterprise is undertaking a major digital transformation to align its technology security controls directly with core business objectives and regulatory compliance drivers. The Chief Information Security Officer (CISO) seeks an enterprise security architecture framework that provides bidirectional traceability—demonstrating how physical security controls map up to business drivers and how business risk appetite translates down to operational controls. Which framework should the CISO select?
An enterprise architecture team is conducting an architectural review of a proposed legacy core banking modernization project using The Open Group Architecture Framework (TOGAF). The team is currently analyzing business processes, organizational structures, and strategic commercial goals to define the target operational state. In which TOGAF architecture domain is the team operating?
A production enterprise database server experiences a zero-day exploit requiring an immediate, out-of-schedule kernel patch to prevent active data exfiltration. The IT security team cannot wait for the standard bi-weekly Change Advisory Board (CAB) meeting. According to ITIL change management governance best practices, how should this change be processed?
During a risk assessment of a global enterprise's IT operations, a CRISC practitioner discovers that unauthorized software installations and manual server configuration modifications frequently bypass the centralized Configuration Management Database (CMDB). What is the most significant operational risk resulting from this condition?