Security architecture is enterprise architecture applied to a specific and increasingly high-stakes domain. It asks the same questions EA always asks — what do we have, how does it connect, who owns it, what are the risks — and adds the security-specific layer: where are the controls, what are the threats, and how do we demonstrate compliance to regulators and auditors?
Sparx EA supports security architecture in ways that most security teams have not fully explored. This article explains the native capability, the frameworks it supports, and how to build a governed, AI-queryable security architecture practice in Sparx EA.
What Security Architecture Modeling Means in Sparx EA
Security architecture in Sparx EA is not a separate product or add-on. It is the application of Sparx EA’s core modeling and repository capabilities to security-specific concerns:
- Threat modeling: Documenting threat actors, attack paths, and affected assets using structured diagrams
- Control mapping: Linking security controls to the assets, processes, and systems they protect
- Framework compliance: Tracing organizational controls to external frameworks (NIST CSF, ISO 27001, CMMC, SOC 2, DORA) to demonstrate coverage and identify gaps
- Security pattern documentation: Encoding reusable security patterns (network segmentation, identity federation, encryption at rest) as model elements that architects can apply consistently across the estate
- Risk register integration: Connecting identified risks to assets and controls within the same repository where the architecture lives
The key advantage of doing this in Sparx EA rather than a point solution (like a GRC tool or a standalone threat modeling tool) is that the security architecture lives in the same model as the rest of the enterprise architecture. A security control links directly to the application it protects, which links to the business capability it supports, which links to the regulatory obligation it satisfies. Traceability is native — you do not have to build it through integrations.
Native Sparx EA Support for Security Architecture
ArchiMate 3.0 Technology Layer
ArchiMate’s Technology layer is the primary modeling language for security architecture in Sparx EA. It provides concepts for:
- Technology services — modeled as the capabilities a security control provides (authentication service, intrusion detection service, key management service)
- Technology interfaces — the points at which security controls interact with the systems they protect
- Technology nodes — physical or virtual infrastructure elements (firewalls, load balancers, identity providers, HSMs)
- Artifacts — certificates, keys, policies, and configuration artifacts that form part of the security posture
ArchiMate 3.0 also includes explicit support for security viewpoints — composite views that show the relationships between assets, threats, and controls in a structured way that auditors and compliance teams can read directly.
Requirements Packages for Control Documentation
Sparx EA’s requirements management capability is well-suited for security control libraries. Each control can be modeled as a requirement with:
- A unique identifier (e.g., ISO 27001 control A.9.1.1 or NIST CSF DE.CM-1)
- A description and implementation status
- Traceability links to the system, process, or data asset it applies to
- Links to evidence artifacts (policy documents, test results, audit outputs)
This creates a living control library inside the architecture repository — not in a separate GRC spreadsheet, but embedded in the model alongside the assets the controls protect.
Traceability From Threat to Control to System
Sparx EA’s core traceability engine — which EA teams use to link business requirements to applications to infrastructure — applies directly to the security domain:
“ Threat Actor → Attack Path → Vulnerable Asset → Security Control → Residual Risk “
Each element in this chain is a model element. Querying the model (with Sparx EA scripts, Kernaro AI Hub, or MCP-connected AI assistants) can answer questions like: “Which applications have no mitigating control for the SQL injection threat?” or “Which ISO 27001 controls do we have no coverage for in our cloud estate?”
Key Frameworks Supported
NIST Cybersecurity Framework (CSF) 2.0
NIST CSF organizes security activity into six functions: Govern, Identify, Protect, Detect, Respond, Recover. Each function contains categories and subcategories that map to specific controls and outcomes.
In Sparx EA, NIST CSF can be modeled as a requirements hierarchy:
- Functions as top-level packages
- Categories as child requirements
- Subcategories as specific control requirements with implementation status tagged values
This allows the organization to see, at a glance, which CSF subcategories are addressed, which are partially addressed, and which are gaps — directly linked to the systems and processes in scope.
ISO 27001:2022
ISO 27001 defines an Information Security Management System (ISMS) and includes Annex A, which lists 93 security controls across four themes: Organizational, People, Physical, and Technological.
In Sparx EA, the ISO 27001 control set can be modeled as a structured requirements package. Each control is linked to:
- The assets it applies to (applications, data stores, infrastructure)
- The processes that implement it (access review, vulnerability scanning, incident response)
- The evidence that demonstrates compliance
This creates a model-driven ISMS that is substantially more traceable than a spreadsheet-based approach and that can be queried by AI tools to identify coverage gaps.
Zero Trust Architecture
Zero Trust is not a single standard but a set of principles: verify explicitly, use least privilege, assume breach. NIST SP 800-207 provides the reference architecture.
Modeling Zero Trust in ArchiMate involves:
- Identity layer: Model the identity provider (IdP), authentication services, and the policy decision point (PDP) as ArchiMate Technology Services
- Policy enforcement points: Model PEPs at each access path — network, application, data layer
- Asset classification: Tag each data asset and application with a sensitivity classification
- Access flow diagrams: ArchiMate flow diagrams showing how a user request travels from endpoint → PEP → PDP → resource, with the control at each step explicit
- Micro-segmentation: Model network segments as ArchiMate Technology Nodes with explicit interfaces, showing what can communicate with what
The resulting model gives security architects a governed, version-controlled representation of the Zero Trust posture — one that can be updated as the architecture evolves and queried by AI assistants to identify gaps.
SABSA (Sherwood Applied Business Security Architecture)
SABSA is a mature enterprise security architecture framework used by large organizations and security consultancies. It provides a layered architecture model (Contextual, Conceptual, Logical, Physical, Component, Operational) that maps closely to how Sparx EA structures its views.
For organizations using SABSA, Sparx EA can be configured with an MDG profile that encodes SABSA concepts as stereotypes — ensuring that SABSA artifacts are modeled consistently and can be queried as first-class elements in the repository.
Regulatory Compliance Mapping Use Cases
SOC 2 Type II
SOC 2 assesses controls against five Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. In Sparx EA, each criterion can be modeled as a requirement package, with specific controls linked to the cloud services, APIs, and data stores in scope. When auditors ask for evidence of control coverage, the architecture model provides the traceability map.
CMMC (Cybersecurity Maturity Model Certification)
CMMC is mandatory for US defense contractors. Its 110 practices (at Level 2) map to NIST SP 800-171 controls. Defense organizations using Sparx EA for DoDAF architecture can extend the same repository to document CMMC control implementation — linking controls to the systems in their CUI (Controlled Unclassified Information) environment.
HIPAA Security Rule
Healthcare organizations using Sparx EA for their application architecture can extend the model to cover HIPAA Security Rule safeguards (Administrative, Physical, Technical) linked to the systems that process Protected Health Information (PHI).
DORA (Digital Operational Resilience Act)
DORA applies to financial entities in the EU and requires documented ICT risk management, incident reporting, and third-party risk management. Sparx EA’s traceability from business process to application to infrastructure to third-party supplier makes it a natural platform for DORA compliance documentation.
MDG Profiles for Security Architecture
The most powerful way to build a security architecture practice in Sparx EA is to define a Security Architecture MDG profile. This extends the standard metamodel with:
- Security stereotypes for threat actors, attack vectors, controls, vulnerabilities, and compliance requirements
- Tagged values for control implementation status, compliance framework reference, risk rating, and evidence location
- Custom diagram types for threat models, control maps, and compliance dashboards
- Toolbox pages that surface security-specific elements to architects working on security views
Once the MDG profile is in place, AI tools connected via MCP can query the repository using security-specific vocabulary: “What controls are tagged as not implemented for systems handling financial data?” or “Which threat actors have no mitigating control in the current architecture?”
This is the capability that separates a governed security architecture practice from a collection of ad hoc diagrams.
Frequently Asked Questions
Do I need a separate tool for threat modeling if I use Sparx EA? Not necessarily. Sparx EA can perform structured threat modeling using ArchiMate diagrams augmented with a security MDG profile. Dedicated threat modeling tools (like Microsoft Threat Modeling Tool or IriusRisk) have workflow features that Sparx EA does not replicate. The choice depends on whether you want a standalone threat modeling workflow or an integrated model where threats are directly linked to the architecture. For mature EA practices, integration is preferable.
Can Sparx EA generate compliance reports for ISO 27001 or SOC 2 audits? Yes, with configuration. Sparx EA’s reporting engine can generate structured documents from the repository — for example, a control coverage matrix showing each ISO 27001 Annex A control, its implementation status, and the linked evidence. This requires the control library to be properly modeled in the repository. Sparx Services can configure standard compliance report templates as part of an Amplify engagement.
How does Zero Trust architecture modeling differ from standard ArchiMate modeling? Zero Trust modeling uses standard ArchiMate concepts but requires specific viewpoints that make the policy enforcement layer explicit. The key difference is focus: standard ArchiMate application views show what communicates with what; Zero Trust views show how access is controlled at each communication path, where the policy decision point sits, and what the identity verification step is. Sparx EA supports both — the difference is in the viewpoints you define and the elements you choose to model.
Is there an MDG profile for NIST CSF or ISO 27001 available out of the box? Not from Sparx Systems directly, but MDG profiles for major security frameworks are available from the Sparx EA community and from consultancies that specialize in security architecture. Sparx Services can develop a custom MDG profile tailored to your compliance requirements as part of an Amplify engagement.
How does Kernaro AI Hub interact with a security architecture model? Kernaro AI Hub can query any element in the Sparx EA repository. If your security architecture is properly modeled — controls linked to assets, threats documented, framework references tagged — Kernaro can answer natural language questions: “Which applications in scope for SOC 2 have no encryption-at-rest control documented?” The quality of AI responses depends directly on the quality and structure of the underlying model.
Can we use Sparx EA for security architecture if we are not already using it for broader EA? Yes, but it is more efficient as part of a broader EA practice. A standalone security architecture repository in Sparx EA is viable, but the primary value — traceability from security control to application to business capability — requires that the application architecture is also in the model. Organizations that are starting with security architecture and considering Sparx EA should plan for eventual integration with the broader architecture repository.
What is the connection between security architecture and the Amplify service? The Amplify service focuses on building architecture practice capability — methodology, MDG configuration, governance frameworks, and team enablement. Security architecture is a domain where Amplify is particularly relevant: establishing a security MDG profile, configuring compliance control libraries, and training architects in security modeling techniques are all Amplify-type activities.
How do we keep a security architecture model current as the environment changes? Currency is the main challenge for any security architecture model. The most effective approaches in Sparx EA are: (1) scripted integration that pulls application and infrastructure inventory from CMDB or cloud provider APIs and updates the model automatically; (2) EA GraphLink connections to ServiceNow or similar sources of truth; (3) regular architecture review cycles with assigned owners for each security domain. The MDG profile can include tagged values for last-reviewed date and responsible owner to support governance.
Building a Security Architecture Practice
If your organization is starting or maturing a security architecture practice and wants to use Sparx EA as the platform, the Amplify service provides the foundation: MDG profile design, control library configuration, compliance reporting setup, and architect training.
CTA: Amplify — Build your security architecture capability in Sparx EA