Security Architecture in Sparx EA: Modeling Zero Trust, NIST CSF, and ISO 27001

Security architecture is enterprise architecture applied to a high-stakes domain. It asks the 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? Modeled in Sparx EA, 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. The traceability comes from the model and does not depend on integrations.

This article covers what that looks like, the frameworks it supports, and how to build a governed, queryable security architecture practice.

The security architect's job is to show which controls protect which assets, where the gaps are, and what evidence supports each claim. By hand, that is a control spreadsheet, a set of diagrams and an audit scramble every year. AI-augmented, the architect decides the framework mapping, the control structure and the rules for what counts as coverage, and AI does the mechanics in the tool and the model: building the control library, linking controls to assets and checking for gaps. The skill is security judgment: knowing what adequate coverage means and checking every mapping before an auditor sees it.

What security architecture modeling means in Sparx EA

Security architecture in Sparx EA uses the core modeling and repository capabilities for security-specific concerns, with no separate product or add-on:

• 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 find gaps
• Security pattern documentation: encoding reusable patterns (network segmentation, identity federation, encryption at rest) as model elements architects apply consistently
• Risk register integration: connecting identified risks to assets and controls within the same repository where the architecture lives

The advantage over a point solution such as 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, so traceability comes with it.

Native Sparx EA support for security architecture

ArchiMate 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 control provides, such as authentication, intrusion detection and key management), technology interfaces (where controls interact with the systems they protect), technology nodes (firewalls, load balancers, identity providers, HSMs), and artifacts (certificates, keys, policies, configuration). Custom viewpoints can combine assets, threats, and controls in one view that auditors and compliance teams can read directly, and The Open Group publishes a risk and security overlay for ArchiMate.

Requirements packages for control documentation

Sparx EA’s requirements management capability suits 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, traceability links to the system, process, or data asset it applies to, and links to evidence artifacts. This creates a living control library inside the architecture repository, instead of a separate GRC spreadsheet. Implementation status and evidence dates are not typed in by hand. AI connects to the governance, risk and compliance, IT service management, project and portfolio management, and IT financial management systems that already hold them, and the model joins that data to the controls and the assets they protect. Dashboards in Prolaborate or Power BI show the posture, which takes less effort, is easier to maintain, and stays current.

Traceability from threat to control to system

Sparx EA’s core traceability engine 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 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 and how they map

Each major framework has a natural representation in a Sparx EA repository. The table summarizes the mapping; the notes below add the detail.

Key frameworks and how they map

Framework	How it maps in Sparx EA
NIST CSF 2.0	Six functions (Govern, Identify, Protect, Detect, Respond, Recover) as top-level packages; categories as child requirements; subcategories as control requirements linked to the systems in scope
ISO 27001:2022	Annex A’s 93 controls across four themes as a structured requirements package, each control linked to its assets, implementing processes, and compliance evidence
Zero Trust (NIST SP 800-207)	Identity provider, PDP, and policy enforcement points as ArchiMate Technology Services and Nodes; access-flow diagrams from endpoint to resource with the control explicit at each step
SABSA	Its six layers (Contextual to Operational) encoded as MDG stereotypes so SABSA artifacts are modeled consistently and queryable as first-class elements

NIST CSF 2.0 modeled as a requirements hierarchy lets the organization see at a glance which subcategories are addressed, partially addressed, or gaps, directly linked to the systems in scope. ISO 27001:2022 becomes a model-driven ISMS that is more traceable than a spreadsheet. Zero Trust is a set of principles (verify explicitly, least privilege, assume breach) and has no single standard behind it; modeling it in ArchiMate makes the policy-enforcement layer explicit, including micro-segmentation modeled as Technology Nodes with explicit interfaces. SABSA maps closely to how Sparx EA structures its views, which is why it encodes cleanly as an MDG Technology profile.

Regulatory compliance mapping use cases

SOC 2 Type II: each of the five Trust Service Criteria modeled as a requirement package, with controls linked to the cloud services, APIs, and data stores in scope. When auditors ask for evidence of control coverage, the model provides the traceability map.

CMMC: mandatory for US defense contractors; its 110 Level 2 practices map to NIST SP 800-171. Defense organizations already using Sparx EA for DoDAF architecture can extend the same repository to document CMMC implementation, linking controls to systems in their CUI environment.

HIPAA Security Rule: healthcare organizations can extend their application architecture to cover Administrative, Physical, and Technical safeguards linked to the systems that process PHI.

DORA: applies to EU financial entities 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 suits DORA documentation.

MDG profiles for security architecture

The strongest foundation for a security practice in Sparx EA is a Security Architecture MDG profile. It extends the standard metamodel with security stereotypes (threat actors, attack vectors, controls, vulnerabilities, compliance requirements), tagged values (framework reference, control owner, risk rating), custom diagram types (threat models, control maps, compliance dashboards), and toolbox pages that surface security-specific elements. Once the profile is in place, the repository can be queried with security-specific vocabulary, such as “which controls have no passing status for systems handling financial data?”, which is what separates a governed practice from a collection of ad hoc diagrams.

Frequently asked questions