Mapping NIST Cybersecurity Framework to Enterprise Archit… | NILUS

⏱ 5 min read

The NIST Cybersecurity Framework (CSF) has become one of the most globally adopted cybersecurity governance models. It offers a structured approach to managing cyber risk through five core functions: Identify, Protect, Detect, Respond, and Recover. Yet in many organizations, NIST CSF implementation remains operational or compliance-focused, disconnected from Enterprise Architecture. This separation weakens traceability, governance alignment, and structural resilience. Sparx EA training

When mapped into Enterprise Architecture, cybersecurity becomes a design property, risk becomes traceable to business capabilities, controls become architectural decisions, resilience becomes measurable, and compliance becomes automatable. Sparx EA best practices

NIST CSF lifecycle

NIST CSF is cyclical and continuous, not a one-time assessment. Each function contains categories and subcategories that must be embedded into enterprise structure. The cycle repeats as threats evolve, the organization changes, and new technologies are adopted.

Enterprise architecture structural layers

Figure 2: EA layers — Business Capabilities to Applications to Data Objects to Infrastructure — **Figure 2:** EA layers — Business Capabilities to Applications to Data Objects to Infrastructure

Security spans all architecture layers and must be modeled structurally. Business Capabilities define what the organization does. Applications implement those capabilities. Data Objects represent the information assets. Infrastructure provides the compute, storage, and network foundation. Each NIST CSF function maps to specific activities across all four layers. ArchiMate relationship types

Identify: risk-aware business architecture

Figure 3: Identify function — Risk to Business Capability to Business Process to Application traceability — **Figure 3:** Identify function — Risk to Business Capability to Business Process to Application traceability

The Identify function aligns with capability mapping, risk prioritization, asset classification, and dependency modeling. Model risks as first-class architecture elements linked to the business capabilities they affect. When a risk is identified (for example, "supply chain data breach"), the architecture model shows which capabilities depend on the affected data, which applications process it, and which infrastructure hosts it. Risk becomes structurally mapped to business impact — not just listed in a spreadsheet. ArchiMate capability map example

Protect: secure architecture design

Figure 4: Protect function — identity-centric protection from User through Identity Provider and Policy Engine to Application and Data Store — **Figure 4:** Protect function — identity-centric protection from User through Identity Provider and Policy Engine to Application and Data Store

Figure 5: Protect function — data-centric protection from Classification through Encryption and Access Policy to Application and Database — **Figure 5:** Protect function — data-centric protection from Classification through Encryption and Access Policy to Application and Database

Protect becomes embedded through identity-first design (centralized identity, MFA, least-privilege), encryption policies (data classification drives encryption requirements), and data-centric protection (access policies derived from data classification, not from application-specific rules). In the architecture model, protection controls are Application Services or Technology Services that serve the business applications they protect — making the protection architecture visible, governable, and traceable.

Detect: observability architecture

Figure 6: Detect function — Applications emitting Logs, Metrics, Traces to SIEM and Monitoring platforms — **Figure 6:** Detect function — Applications emitting Logs, Metrics, Traces to SIEM and Monitoring platforms

Detection must be designed into application and infrastructure layers, not bolted on after deployment. Every application emits structured logs, metrics, and traces. A centralized SIEM correlates events across sources. Automated anomaly detection identifies patterns that human operators would miss. In the architecture model, detection components (SIEM, monitoring platform, APM) are modeled as shared Application Services with dependencies on every application they monitor.

Respond: incident architecture

Figure 7: Respond function — Alert to SOC to Triage to Isolation to Remediation workflow — **Figure 7:** Respond function — Alert to SOC to Triage to Isolation to Remediation workflow

Response must map to system ownership and architectural dependencies. When an incident is detected, the architecture model provides: who owns the affected system (for escalation), what other systems depend on it (for impact assessment), what isolation actions are available (for containment), and what the recovery procedure is (for remediation). Without this architectural context, incident response relies on tribal knowledge — which fails at 3 AM when the person who knows is unavailable.

Recover: resilience engineering

Figure 8: Recover function — Global DNS routing to Region A and Region B with replicated databases — **Figure 8:** Recover function — Global DNS routing to Region A and Region B with replicated databases

Recovery planning aligns with RTO (how fast must we recover?), RPO (how much data can we lose?), and business criticality (which capabilities must recover first?). Multi-region deployment with replicated databases ensures that regional failures do not stop the business. The architecture model defines recovery tiers: Tier 1 (critical — 15-minute RTO), Tier 2 (important — 4-hour RTO), Tier 3 (standard — 24-hour RTO). Each application is assigned a recovery tier, and the infrastructure architecture is designed to meet those targets.

Governance integration and traceability

Figure 9: Governance — Initiative to Architecture Design to Security Review to Implementation to Monitoring — **Figure 9:** Governance — Initiative to Architecture Design to Security Review to Implementation to Monitoring

Figure 10: Traceability — Threat to Risk to Capability to Application to Infrastructure chain — **Figure 10:** Traceability — Threat to Risk to Capability to Application to Infrastructure chain

Security becomes an architectural checkpoint within governance workflows. Every initiative passes through architecture design, which includes a mandatory security review. The review validates that the proposed architecture implements required controls, uses approved patterns, and maintains the traceability chain from threats through risks to capabilities to applications to infrastructure to controls. This traceability enables audit transparency and investment prioritization — money goes where risk is highest and architectural gaps are widest. ARB governance with Sparx EA

Figure 11: DevSecOps alignment — Code Commit to CI to Security Scan to Deployment to Monitoring — **Figure 11:** DevSecOps alignment — Code Commit to CI to Security Scan to Deployment to Monitoring

Security controls become automated within CI/CD pipelines. NIST CSF's Protect function maps directly to pipeline security gates (SAST, dependency scanning, container scanning). The Detect function maps to runtime monitoring integrated into the deployment pipeline. This closes the loop: architecture defines the controls, pipelines enforce them, and monitoring validates them continuously.

Frequently Asked Questions

What is enterprise architecture?

Enterprise architecture is a discipline that aligns an organisation's strategy, business operations, information systems, and technology infrastructure. It provides a structured framework for understanding how an enterprise works today, where it needs to go, and how to manage the transition.

How is ArchiMate used in enterprise architecture practice?

ArchiMate is used as the standard modeling language in enterprise architecture practice. It enables architects to create consistent, layered models covering business capabilities, application services, data flows, and technology infrastructure — all traceable from strategic goals to implementation.

What tools are used for enterprise architecture modeling?

Common enterprise architecture modeling tools include Sparx Enterprise Architect (Sparx EA), Archi, BiZZdesign Enterprise Studio, LeanIX, and Orbus iServer. Sparx EA is widely used for its ArchiMate, UML, BPMN and SysML support combined with powerful automation and scripting capabilities.