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

The short version: security architecture is enterprise architecture applied to a 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? 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. Traceability is native — you do not build it through integrations.

Most security teams have not fully explored this. Below: the native capability, the frameworks it supports, and how to build a governed, queryable security architecture practice.

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 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 — 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 is built in rather than bolted on.

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 — authentication, intrusion detection, 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). ArchiMate also includes explicit support for security viewpoints — composite views showing the relationships between assets, threats, and controls in a way auditors and compliance teams can read directly.

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 and implementation status, 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 — not in a separate GRC spreadsheet.

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.

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 with implementation-status tagged values
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 substantially more traceable than a spreadsheet. Zero Trust is not a single standard but a set of principles (verify explicitly, least privilege, assume breach); 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 makes it a natural platform for DORA documentation.

MDG profiles for security architecture

The most powerful way to build a security practice in Sparx EA is to define a Security Architecture MDG profile. It extends the standard metamodel with security stereotypes (threat actors, attack vectors, controls, vulnerabilities, compliance requirements), tagged values (control status, framework reference, risk rating, evidence location), 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 — “what controls are tagged not-implemented for systems handling financial data?” — which is the capability that separates a governed practice from a collection of ad hoc diagrams.

Frequently asked questions