Security Architecture Domain Module

Enabling protection without becoming the blocker.

Security Architecture is where risk meets reality. It defines how the organisation protects its assets, manages identity, implements controls, and maintains compliance — not as an afterthought or a gate at the end, but as an enabling constraint woven through every architectural decision.

Unfortunately, most organisations treat security as either a checklist to be ticked or a department that says "no." Neither works. Checklists create compliance theatre — boxes get ticked, but systems aren't actually secure. Security-as-blocker creates workarounds — teams find ways around the gates because they have delivery pressures that don't wait.

Security Architecture, done right, provides guardrails that make the secure path the easy path. Done poorly, it produces documentation nobody reads and controls that get bypassed the moment they become inconvenient.

This module provides the practical foundation for security architecture that integrates with governance and enables delivery rather than blocking it.

What This Module Provides

How It Plugs Into the Governance Core

Security Architecture doesn't operate in isolation. It connects to every component of the Governance Core — and frankly, it should influence all of them.

Guardrails Framework — Security guardrails define the non-negotiables. "Multi-factor authentication for all user accounts." "Encryption at rest for sensitive data." "Penetration testing before internet-facing deployments." Unlike other guardrail categories where deviation might be acceptable with justification, security guardrails often have less flexibility — some things simply aren't optional.

Decision Records — When a decision has security implications, the security context gets captured. "We accepted the risk of using this legacy authentication method because the system is being decommissioned in 6 months, with compensating controls documented." Security decisions need traceability more than most — when incidents happen, you need to understand what was decided and why.

Architecture Passport — Each system's passport includes its security classification, applicable controls, compliance status, and any security debt. This makes security posture visible across the portfolio without requiring separate security documentation that drifts out of sync.

Tiered Oversight — Security risk factors heavily into oversight tier. Systems handling protected data, internet-facing applications, or integrating with external parties typically warrant higher scrutiny. The tier assessment explicitly includes data sensitivity and compliance impact.

Technical Debt Register — Security debt is often the most consequential category. Unpatched systems, deprecated authentication, missing controls, deferred penetration testing — all need visibility and active management. Security debt that's invisible is security debt that becomes an incident.

Architecture Registry — This module populates the security layer of your registry: security classifications, control implementations, compliance mappings, and the relationships between them.

Core Artefacts

Security Reference Architecture

A Security Reference Architecture provides a consistent mental model for how security is structured across the organisation. It's not a detailed design — it's a framework that shapes detailed designs.

Why it matters: Without a reference architecture, every solution architect makes different assumptions about security boundaries, identity models, and control placement. You end up with inconsistent security posture, duplicated controls in some places and gaps in others, and no coherent way to assess the portfolio.

The reference architecture should be simple enough to remember and apply, but comprehensive enough to cover the key security domains.

Example: Layered Security Model

This is one approach — adapt it to your context.

┌─────────────────────────────────────────────────────────────────┐
│                        GOVERNANCE LAYER                         │
│  Policy │ Standards │ Risk Management │ Compliance │ Assurance  │
├─────────────────────────────────────────────────────────────────┤
│                        IDENTITY LAYER                           │
│  Authentication │ Authorisation │ Directory │ Privileged Access │
├─────────────────────────────────────────────────────────────────┤
│                       PERIMETER LAYER                           │
│  Network Security │ Web Application Firewall │ DDoS Protection  │
├─────────────────────────────────────────────────────────────────┤
│                      APPLICATION LAYER                          │
│  Secure Development │ API Security │ Input Validation │ Secrets │
├─────────────────────────────────────────────────────────────────┤
│                         DATA LAYER                              │
│  Classification │ Encryption │ Masking │ DLP │ Backup/Recovery  │
├─────────────────────────────────────────────────────────────────┤
│                      ENDPOINT LAYER                             │
│  Device Management │ EDR │ Patching │ Configuration Hardening   │
├─────────────────────────────────────────────────────────────────┤
│                      OPERATIONS LAYER                           │
│  Monitoring │ Logging │ SIEM │ Incident Response │ Threat Intel │
└─────────────────────────────────────────────────────────────────┘

Governance Layer sits above everything — it's where security policy, risk appetite, and compliance requirements are defined. This layer doesn't implement controls; it defines what controls are needed and why.

Identity Layer is the foundation of modern security. Who are you? What are you allowed to do? How do we verify that? Zero Trust architectures treat identity as the primary security perimeter, and for good reason — network perimeters are increasingly porous.

Perimeter Layer still matters, even in a Zero Trust world. Defence in depth means multiple layers, and network-level controls remain valuable for reducing attack surface and providing visibility.

Application Layer is where many vulnerabilities live. Secure coding practices, input validation, secrets management, and API security are often the difference between a secure system and a breach.

Data Layer protects the thing that actually matters — the information. Classification drives proportionate controls. Encryption protects data at rest and in transit. Backup and recovery ensure resilience.

Endpoint Layer covers the devices that access your systems — whether corporate laptops, mobile devices, or servers. Hardening, patching, and endpoint detection are table stakes.

Operations Layer is how you detect, respond, and recover. Without logging and monitoring, you're blind. Without incident response capability, detection is useless.

Using the Reference Architecture

The reference architecture serves several purposes:

For solution architects: It provides a checklist of security considerations. "Have I addressed identity? Perimeter? Application security? Data protection?" It ensures nothing gets forgotten.

For security architects: It provides a consistent vocabulary for discussing security across solutions. Instead of bespoke security documentation for every system, you can reference the layers and focus on what's specific to this solution.

For governance: It provides a framework for assessing security posture across the portfolio. "How mature is our identity layer across Tier 1 systems? Where are the gaps in our operations layer?"

Control Framework Alignment

Most organisations operate under one or more security compliance frameworks. Australian government agencies work with Essential Eight and ISM. Others align to NIST Cybersecurity Framework, CIS Controls, or ISO 27001. Many organisations have multiple frameworks that apply.

Why it matters: Compliance frameworks provide structure and external validation, but they can also create confusion. Teams don't know which controls apply. Multiple frameworks create duplication and inconsistency. Audit preparation becomes a scramble to demonstrate compliance.

Control framework alignment creates a single view of what controls exist, which frameworks they satisfy, and where gaps remain.

Framework Selection Considerations

You don't have to choose just one. Many organisations use a primary framework for compliance purposes and reference others for specific guidance. The key is knowing which controls apply and maintaining traceability.

Control Mapping Approach

Rather than maintaining separate documentation for each framework, create a unified control register that maps to all applicable frameworks:

This approach means:

• One source of truth for control status
• Multiple frameworks satisfied by the same evidence
• Clear gap visibility across all frameworks
• Efficient audit preparation

Security Classification Model

Not all assets need the same level of protection. A public website and a system processing protected health information have vastly different security requirements. Classification provides the basis for proportionate security.

Why it matters: Without classification, you either under-protect sensitive assets (risk) or over-protect everything (cost and friction). Classification enables risk-based decisions about control investment.

Classification Dimensions

Data Classification — What's the sensitivity of the information?

System Criticality — What's the impact if this system is unavailable or compromised?

Classification drives controls: A system classified as Critical handling Protected data warrants maximum security investment. A Low-criticality system handling Public data needs basic hygiene but not enterprise security controls.

Integration with Tiered Oversight

Classification aligns directly with the Governance Core's tiered oversight model:

Security Guardrails

Security guardrails define the non-negotiables and the risk-based boundaries within which teams operate. They embody the organisation's security risk appetite in actionable terms.

Why it matters: Without clear guardrails, every security decision requires escalation. Teams either wait for security approval (bottleneck) or make their own calls (inconsistency and risk). Guardrails enable autonomy within defined boundaries.

Guardrail Categories

Non-Negotiable Controls — Things that are simply required, regardless of context:

• "Multi-factor authentication is mandatory for all user accounts accessing corporate systems"
• "All data at rest must be encrypted using approved algorithms"
• "Internet-facing applications require penetration testing before go-live"
• "Privileged access requires just-in-time provisioning and session recording"

These guardrails have minimal deviation pathways. If you can't meet them, you probably can't proceed — or you need significant compensating controls and formal risk acceptance.

Risk-Based Controls — Controls that scale with classification:

• "Systems handling Protected data must implement [specific controls]"
• "External integrations require security assessment proportionate to data sensitivity"
• "Third-party access requires [controls] based on access level"

These guardrails provide flexibility based on context while ensuring proportionate protection.

Architectural Principles — Security approaches that guide design:

• "Zero Trust: verify explicitly, use least privilege access, assume breach"
• "Defence in depth: no single control is sufficient"
• "Secure by default: systems should be secure out of the box, not require hardening"

Example: Zero Trust as a Guardrail

Zero Trust isn't a product — it's an architectural approach. As a guardrail, it might be expressed as:

Guardrail: Zero Trust Principles

Statement: All new solutions must implement Zero Trust principles: verify explicitly (authenticate and authorise every access request), use least privilege access (just enough access, just in time), and assume breach (design for detection and containment, not just prevention).

Rationale: Traditional perimeter-based security is insufficient for modern hybrid environments where users, devices, and applications exist inside and outside traditional network boundaries.

Application: - Authentication at every access point, not just network entry - Authorisation based on identity, device health, and context - Microsegmentation to limit lateral movement - Continuous verification, not single sign-on without re-validation - Logging and monitoring to detect anomalies

Deviation: Legacy systems that cannot implement Zero Trust principles require documented compensating controls and a roadmap to compliance or retirement.

Threat Context

Security architecture should be informed by understanding of actual threats, not just compliance requirements. Threat context grounds security decisions in reality.

Why it matters: Without threat awareness, security investment is driven by compliance checklists or vendor marketing rather than actual risk. Understanding threats enables prioritisation — focusing investment where attacks are most likely and most consequential.

Maintaining Threat Awareness

You don't need a threat intelligence team to maintain threat context. At minimum:

Industry threat landscape — What attacks are common in your sector? Healthcare faces different threats than manufacturing. Government faces different threats than retail.

Known attack patterns — How do attackers typically gain access and achieve their objectives? Phishing, credential theft, vulnerability exploitation, supply chain compromise — understanding the patterns shapes defensive priorities.

Organisational context — What makes your organisation a target? What assets would attackers want? What's your external exposure?

Threat-Informed Control Prioritisation

Essential Eight exists because the Australian Signals Directorate analysed actual incidents and identified the mitigations that would have prevented them. That's threat-informed prioritisation.

Apply the same thinking to your context:

Integration with Other Domain Modules

Security Architecture shapes and is shaped by every other domain:

Security Architecture often operates as a cross-cutting concern — informing decisions in other domains rather than making decisions independently. The security architect's job is frequently to translate security requirements into terms that solution architects and technology teams can implement.

What Success Looks Like

You know Security Architecture is working when:

Outcome Indicators:

• Security is considered early in solution design, not bolted on at the end
• Teams can self-assess against security guardrails without waiting for security review
• Security incidents that could have been prevented by known controls are rare
• Compliance audits are routine, not crisis events
• Security debt is visible and actively managed, not hidden until it becomes an incident
• New solutions are more secure than old ones — the baseline is rising

Metric Indicators:

Health Indicators:

Anti-Patterns to Avoid

Extending to SABSA

XAF Security Architecture provides the governance-connected fundamentals. For organisations wanting comprehensive security architecture practice, SABSA (Sherwood Applied Business Security Architecture) offers a methodology that builds naturally on this foundation.

How they fit together:

For those pursuing SABSA certification (SCF, SCP, SCM), this provides professional development pathways that complement XAF implementation.

The goal isn't XAF or SABSA — it's XAF for governance integration, with SABSA methodology available for those wanting comprehensive security architecture practice.

Start with what XAF provides. Extend when you need more depth.

Getting Started

If you're establishing Security Architecture capability for the first time, don't try to cover everything at once.

Week 1: Minimum Viable Security Guardrails

1. Identify your non-negotiables — What are the absolute security requirements you already know? MFA, encryption, patching? Write them down as guardrails.
2. Choose your primary compliance framework — Which framework drives your compliance requirements? Essential Eight? ISO 27001? NIST? Pick one as primary.
3. Draft a basic classification model — Even just three levels (Public, Internal, Sensitive) is better than no classification.
4. Establish the deviation process — Who approves security exceptions? What documentation is required? Even informal process is better than none.
5. Publish and communicate — Even rough security guardrails are better than none. Get them in front of solution architects.

Month 1: Control Framework Alignment

1. Map your existing controls — What security controls already exist? Document them, even informally.
2. Align to framework — Map existing controls to your primary compliance framework. Identify gaps.
3. Prioritise gaps — Not all gaps are equal. Which gaps represent actual risk versus compliance paperwork?
4. Create the unified control register — Single source of truth for control status and framework mapping.
5. Connect to passports — Add security classification and control status to Architecture Passports.

Month 2-3: Security Reference Architecture

1. Draft your reference architecture — Adapt the example or create your own. Keep it simple enough to remember.
2. Socialise with architects — Get feedback from solution architects. Does it help them think about security?
3. Embed in design process — Reference architecture becomes a checklist in solution design.
4. Add to registry — Security architecture artefacts populate the Architecture Registry.

Month 3+: Full Security Assurance

1. Integrate with tiered oversight — Security classification drives oversight tier.
2. Establish security debt tracking — Security technical debt visible alongside other debt.
3. Build threat awareness — Regular threat landscape updates inform priorities.
4. Metrics and reporting — Security posture visible in architecture governance reporting.
5. Continuous improvement — Guardrails evolve based on incidents, audits, and changing threats.

The goal is security architecture that genuinely improves security posture — not documentation that satisfies auditors but doesn't change anything.

Related Guardrails

Security guardrails typically reference this module's artefacts:

Example security guardrails:

• "Systems handling Protected data must implement controls specified in the security classification baseline for that level"
• "All new solutions must demonstrate compliance with applicable security guardrails before production deployment"
• "Internet-facing applications require security architecture review as part of Tier 1 or Tier 2 oversight"
• "Third-party integrations require security assessment proportionate to data sensitivity and access level"
• "Security exceptions require documented compensating controls and formal risk acceptance"

Guardrail ID: [GRL-SEC-XXX]
Name: [Guardrail name]
Category: Security

Statement:
[Clear, actionable statement of the guardrail]

Rationale:
[Why this guardrail exists]

Classification Applicability:
[Which classification levels this applies to]

Framework Alignment:
[Which framework requirements this satisfies]

Deviation Process:
[How to request deviation]

Related Guardrails:
[Links to related guardrails from other domains]

Populating the Architecture Registry

This module provides the content that populates the security layer of your Architecture Registry. If you've established the registry structure from the Governance Core but have empty security sections, this is where the content comes from.

What goes in the registry:

Relationship integrity: The power of the registry comes from relationships. Every system should link to its security classification. Every control should link to the systems where it's implemented. Every guardrail should link to the controls that satisfy it. Without these relationships, you have lists instead of architecture.

The Bottom Line

Security Architecture in XAF provides:

• Guardrails, not gates — Enable teams to make secure decisions autonomously within defined boundaries
• Classification-driven — Proportionate security based on actual risk, not one-size-fits-all
• Framework-aligned — Compliance requirements satisfied through unified control management
• Governance-integrated — Security embedded in architecture governance, not parallel to it
• Threat-informed — Security priorities grounded in actual threat landscape, not just compliance checklists

Security shouldn't be the department of "no." It should be the function that makes the secure path the easy path.

XAF Connected Architecture | Developed by InnovateX Solutions