ISO 27001 A.8.27: Secure System Architecture and Engineering Principles

Quick Reference (60 Seconds)

Control: A.8.27, Secure System Architecture and Engineering Principles
Purpose: Ensure information systems are designed and built using security architecture principles and engineering best practices, reducing vulnerabilities at the design level rather than patching them later.
ISO 27002 attributes: Control type: Preventive · Properties: Confidentiality, Integrity, Availability · Concepts: Protect · Capabilities: Application security, System and network security · Domains: Protection
Who it applies to: All organizations that design, develop, acquire, or significantly modify information systems.
Minimum viable actions:

• Adopt and document security architecture principles (defense in depth, least privilege, etc.)
• Review all system architectures for security before development or procurement
• Maintain architecture decision records (ADRs) with security rationale
• Establish an architecture review board with security representation

Key deliverables: Security Architecture Principles Document, Architecture Review Board Charter, Architecture Decision Records (ADRs), Security Architecture Review Report.

Audit questions you should be able to answer:

• What security architecture principles does your organization follow?
• Can you show me the security architecture review for [system name]?
• Who reviews system architectures for security?
• How do you ensure security is designed into systems, not added later?

What the Control Asks For

Do you need this control?

A.8.27 is not mandatory in itself: under clause 6.1.3 you include it if your risk assessment calls for it, and record the decision in your Statement of Applicability. Include it if you design or engineer systems, including cloud architectures. Organisations that only buy packaged systems may meet much of it through supplier requirements.

Annex A 8.27 asks organizations to establish, document, maintain, and apply secure system engineering principles to development activities.

What ISO 27002:2022 Adds

ISO/IEC 27002:2022 (8.27), paraphrased:

• Design security into every architecture layer: business, data, applications and technology. Analyse new technology for security risks and review designs against known attack patterns.
• Engineering principles should guide authentication, secure session control, and data validation and sanitisation.
• Analyse: (a) the full range of controls needed against identified threats; (b) whether controls can prevent, detect or respond; (c) controls specific to business processes (encryption, integrity checks, digital signatures); (d) where and how controls are applied in the architecture and infrastructure; (e) how manual and automated controls work together as one set.
• Take account of: (a) integration with a security architecture; (b) the technical security infrastructure (PKI, IAM, DLP, dynamic access management); (c) the organisation's ability to build and support the chosen technology; (d) the cost, time and complexity of meeting the requirements; (e) current good practice.
• Secure engineering involves: (a) architecture principles such as security by design, defence in depth, security by default, default deny, fail securely, distrust input from external applications, security in deployment, assume breach, least privilege, usability and manageability, and least functionality; (b) a security-oriented design review; (c) documenting and formally acknowledging controls that do not fully meet requirements (for example where safety requirements override them); (d) hardening.
• Consider zero-trust principles: assume breach, never trust and always verify, encrypt requests end to end, treat internal requests as if from an open network, use least privilege and dynamic, context-based access control (5.15, 5.18, 8.2), and always authenticate and authorise requests (5.16, 5.17, 8.5).
• Apply the principles to outsourced development through contracts, and check that suppliers' engineering practice fits your needs.
• Review the principles and engineering procedures regularly so they keep improving security and stay current with new threats and technologies.

In practice you will also want an architecture review gate, architecture decision records and traceability from requirements to design. These are good practice rather than words in the standard.

What the Standard Does NOT Require

• The standard does not mandate a specific architecture framework (TOGAF, SABSA, etc.)
• It does not require all systems to use the same architecture pattern
• It does not specify particular technologies or vendors
• It does not require formal architecture review for trivial changes or maintenance-only systems

Why Secure System Architecture Matters

Architecture Flaws Are the Most expensive to Fix

Architecture-level flaws cost far more to fix after deployment than during design. (A widely quoted "100 times" figure is hard to trace to a primary source, so treat exact multipliers with caution.) The reason is that architecture flaws are structural:

• They require redesigning the system
• They cascade through multiple components
• They may require changes to infrastructure, interfaces, and integrations
• They often require retraining users and updating documentation

Examples of architecture-level security flaws:

• Single point of failure in authentication (all services rely on one identity provider with no fallback)
• No separation of duties in critical workflows (one user can approve and execute financial transactions)
• Hardcoded secrets in architecture (API keys embedded in code rather than managed by a vault)
• No encryption in transit between microservices (internal network assumed "trusted")
• Monolithic design preventing isolation of compromised components

The Security Architecture Mindset

Secure system architecture is not about adding security features. It is about designing the system so that security is an emergent property:

• Defense in depth: No single control is the only line of defense
• Fail secure: When components fail, the system fails to a secure state
• Least privilege: Components have only the minimum access needed
• Separation of duties: Critical functions require multiple actors
• Economy of mechanism: Simplicity reduces attack surface
• Complete mediation: Every access request is checked
• Open design: Security does not rely on secrecy of design
• Least common mechanism: Shared mechanisms are minimized
• Psychological acceptability: Security does not impede legitimate use

The Indian Context

Indian organizations face unique architectural challenges:

• Digital India initiatives: Government services require secure architecture for citizen data (Aadhaar, UPI, DigiLocker)
• UPI ecosystem: more than 10 billion transactions a month since August 2023 (NPCI); payment architecture must handle that scale securely
• Fintech growth: many fintechs must design for RBI expectations from the start
• Cloud migration: Organizations moving from on-premise to cloud need architecture redesign for cloud-native security
• AI/ML adoption: Indian enterprises adopting AI need secure architecture for model serving, data pipelines, and inference
• DPDP Act 2023: architecture must support notice (s.5), consent and its withdrawal (s.6), reasonable security safeguards (s.8(5)) and erasure (s.8(7))
• Data location shapes architecture: RBI's 2018 directive requires payment system data to be stored only in India; Companies (Accounts) Rules 2014, Rule 3(5), require a daily backup of electronic books of account on servers in India; CERT-In's 2022 Directions require ICT logs to be kept within India for 180 days. Design regions, backups and log pipelines with these in mind.
• OT/IT convergence: Manufacturing and critical infrastructure need secure architecture for industrial IoT

Scope and Applicability

In Scope

This control applies to:

• New system architecture: Whether for in-house development, outsourced development, or COTS integration
• Major architecture changes: Refactoring, migration, re-platforming, cloud migration
• Integration architectures: How systems connect and share data
• Cloud-native architectures: Microservices, serverless, container orchestration
• Mobile architectures: Client-server, offline-first, API-driven
• AI/ML architectures: Training pipelines, inference serving, model management
• IoT/OT architectures: Edge computing, device management, industrial control
• API architectures: Gateway patterns, service mesh, event-driven

Out of Scope (with caveats)

• Minor configuration changes: Settings adjustments within existing architecture
• Bug fixes: Patching without architecture impact
• Routine maintenance: Updates that don't change architecture
• End-user changes: Application settings, permissions within defined parameters

Caveat: Cloud migration, microservices decomposition, API introduction, or AI integration are NOT "minor changes", they are architecture changes requiring full security review.

Applicability by Organization Type

Key Definitions and Terminology

Relationship to Other Controls

Directly Related Controls

Framework Mapping

Implementation Roadmap (Week-by-Week)

Figure · Tiers

Maturity levels for secure system architecture and engineering principles

Phase 1: Foundation (Weeks 1–3)

Week 1: Architecture Principles Definition

• Define 8-12 security architecture principles for the organization
• Align principles with business strategy and risk appetite
• Document principles with rationale and examples
• Obtain management approval

Week 2: Architecture Review Process

• Define the security architecture review process
• Establish the Architecture Review Board (ARB) with security representation
• Create the architecture review checklist
• Define criteria for when a security architecture review is required

Week 3: Reference Architecture and Patterns

• Develop a secure reference architecture for common system types
• Identify and document security patterns (authentication, authorization, encryption, logging)
• Create Architecture Decision Record (ADR) template
• Establish architecture documentation standards

Deliverables: Security Architecture Principles Document, ARB Charter, Reference Architecture, ADR Template, Review Checklist

Phase 2: Pilot (Weeks 4–6)

Week 4-5: Pilot System Review

• Select 2-3 systems for pilot security architecture review
• Conduct architecture reviews using the checklist and principles
• Document ADRs for major security decisions
• Identify gaps and improvement opportunities

Week 6: Refinement

• Refine principles based on pilot findings
• Update reference architecture with lessons learned
• Improve review process based on feedback
• Update templates and checklists

Deliverables: Pilot review reports, Updated principles, Refined reference architecture, Improved process

Phase 3: Rollout (Weeks 7–10)

Week 7-8: Process Integration

• Integrate security architecture review into SDLC/project management gates
• Train architects, developers, and security team on principles and process
• Deploy reference architecture and patterns to all new projects
• Establish architecture repository

Week 9-10: Full Deployment

• Apply to all new systems and major architecture changes
• Conduct quality assurance on architecture reviews
• Establish metrics collection
• Deploy architecture documentation tools

Deliverables: Integrated process, Training records, Architecture repository, Metrics baseline

Phase 4: Optimization (Weeks 11–14)

Week 11-12: Metrics and Monitoring

• Collect and analyze KPIs (see Section 13)
• Conduct first internal audit of architecture process
• Identify gaps and improvement opportunities

Week 13-14: Continuous Improvement

• Update principles with new threats and technologies
• Automate architecture review where possible (IaC scanning, architecture linting)
• Integrate with CI/CD for architecture validation
• Update training materials

Deliverables: KPI dashboard, Internal audit report, Updated principles, Automated checks

Maturity Model

Detailed Implementation Guidance

Core Security Architecture Principles

Organizations should adopt and document 8-12 security architecture principles. Here are the most critical:

Principle 1: Defense in Depth

Statement: No single security control is sufficient. Systems must be designed with multiple independent layers of security so that if one layer is compromised, others remain effective.

Rationale: Attackers will eventually find a way past any single control. Layered defense provides resilience and time for detection and response.

Implementation:

• Network: Firewall + IDS/IPS + network segmentation + endpoint protection
• Application: Authentication + authorization + input validation + output encoding + logging
• Data: Encryption at rest + encryption in transit + access controls + backup encryption
• Identity: Password + MFA + device trust + behavioral analytics

Example: A web application uses WAF (network layer), authentication (application layer), RBAC (application layer), input validation (application layer), database encryption (data layer), and SIEM monitoring (detection layer).

Principle 2: Least Privilege

Statement: Every component, user, and process must operate with the minimum privileges necessary to perform its function. Privileges are granted explicitly and revoked when no longer needed.

Rationale: Excessive privileges increase the damage from compromise (lateral movement, privilege escalation, data exfiltration).

Implementation:

• User accounts: Role-based access control with fine-grained permissions
• Service accounts: One service = one account, minimal permissions
• Database: Application user has only necessary table permissions
• Containers: Run as non-root, read-only filesystems, minimal capabilities
• Cloud: IAM policies with least privilege, temporary credentials

Example: A payment processing service has database access only to the payment_transactions table, not to customer_profiles or audit_logs.

Principle 3: Fail Secure

Statement: When a system or component fails, it must fail to a secure state. No failure should expose data, grant unauthorized access, or disable security controls.

Rationale: Systems will fail. The question is whether failure helps attackers or protects the system.

Implementation:

• Authentication failure: Deny access, log event, alert (not bypass)
• Database connection failure: Queue transactions, do not process without validation
• Encryption failure: Do not transmit data in plaintext
• Firewall failure: Block all traffic (default deny), not allow all
• Service failure: Circuit breaker opens, requests fail fast

Example: If the authentication service is unavailable, the application denies all access rather than allowing anonymous access or using cached credentials indefinitely.

Principle 4: Separation of Duties

Statement: Critical functions must require the involvement of multiple independent actors. No single person should be able to complete a sensitive end-to-end process alone.

Rationale: Insider threats, errors, and compromised accounts are mitigated when multiple people are required for critical actions.

Implementation:

• Financial: Requester approves budget, different person approves payment, third person executes
• Code deployment: Developer writes, reviewer approves, separate person deploys
• Data deletion: Admin requests, manager approves, auditor logs
• System configuration: Engineer changes, security reviews, operations deploys

Example: In a banking system, a teller can initiate a wire transfer, but a supervisor must approve it, and the system automatically logs both actions.

Principle 5: Economy of Mechanism

Statement: Security mechanisms should be as simple and small as possible. Complexity is the enemy of security.

Rationale: Complex systems have more bugs, more attack surface, and are harder to understand, test, and audit.

Implementation:

• Use well-tested libraries instead of custom security code
• Minimize the number of security mechanisms in the system
• Reduce the codebase to the minimum necessary
• Simplify architecture: fewer components, clear interfaces, well-defined responsibilities
• Avoid unnecessary features that increase attack surface

Example: Instead of a custom authentication system with 10 features, use a standard OAuth 2.0 / OIDC implementation with 3 well-tested features.

Principle 6: Complete Mediation

Statement: Every access to every resource must be checked for authorization. No access is granted based on previous checks or assumed trust.

Rationale: Cached permissions, assumed trust, and incomplete checks lead to authorization bypasses.

Implementation:

• Every API request validates the JWT token and permissions
• Every database query checks row-level security
• Every file access checks user permissions
• Every admin action validates admin role (not just "is logged in")
• Session timeouts enforce re-authentication for sensitive actions

Example: A user with a valid session token attempts to access admin functionality. The system checks: (1) Is the token valid? (2) Is the user in the admin role? (3) Is the user's account active? (4) Is the action within the user's scope? All four checks must pass.

Principle 7: Open Design

Statement: Security should not depend on the secrecy of the design or implementation. The system should be secure even if the attacker knows how it works.

Rationale: "Security through obscurity" fails when the design is inevitably leaked or reverse-engineered.

Implementation:

• Use well-known, peer-reviewed cryptographic algorithms (AES, RSA, ECDSA)
• Publish security architecture for review (internal or external)
• Assume attackers know the system design in threat models
• Do not rely on hidden URLs, undocumented APIs, or obfuscated code for security
• Open source security components where possible for community review

Example: The security of a password hashing system relies on the strength of bcrypt/Argon2 and the secrecy of passwords, not on the secrecy of the hashing algorithm.

Principle 8: Least Common Mechanism

Statement: Minimize the amount of mechanisms and resources shared by different users or processes. Shared mechanisms can become single points of failure or compromise.

Rationale: Shared mechanisms create covert channels, privilege escalation paths, and collateral damage from compromise.

Implementation:

• Separate databases per tenant (multi-tenant architecture with isolation)
• Separate service accounts per application
• Separate network segments per security domain
• Separate logging per application (with centralized aggregation)
• Separate encryption keys per data classification level

Example: In a SaaS platform, each customer's data is in a separate database schema with separate encryption keys, not in one shared table with customer_id filtering.

Principle 9: Psychological Acceptability

Statement: Security mechanisms must be user-friendly and not overly burdensome. If security is too difficult, users will circumvent it.

Rationale: Security that users bypass is not security. The system must balance security with usability.

Implementation:

• Single sign-on (SSO) instead of multiple logins
• Context-aware MFA (MFA for high-risk actions, not every action)
• Clear error messages that help users (without information leakage)
• Self-service password reset with secure verification
• Minimal security steps for low-risk actions

Example: A banking app requires password + biometric for login, but only biometric for balance check. Wire transfers require password + biometric + OTP.

Principle 10: Zero Trust

Statement: No user, device, or system is trusted by default, regardless of network location or previous authentication. Trust is continuously verified.

Rationale: Perimeter-based security is obsolete. Attackers who breach the perimeter have unrestricted access inside.

Implementation:

• Verify identity for every request, not just at network entry
• Micro-segmentation: Every service is isolated, every connection is authenticated
• Continuous verification: Re-check trust based on behavior, device health, and risk signals
• Assume breach: Monitor for lateral movement, insider threats, and compromised credentials
• No implicit trust based on IP address, network location, or VPN

Example: A developer on the corporate VPN accessing a production database must still authenticate with MFA, pass device health checks, and have explicit authorization for that specific database.

Mapping These Principles to ISO 27002 8.27

Principle 11: Distrust Input from External Applications

Treat every input from another system, partner API, webhook or file as untrusted until validated: check schemas, signatures, sizes and types, and never pass it straight to an interpreter, query or command.

Principle 12: Security in Deployment

Deployment pipelines, infrastructure as code and runtime configuration are part of the design: signed artefacts, least-privilege pipeline identities, hardened images, and configuration checked before release.

Principle 13: Usability and Manageability

A control that users bypass or operators cannot run does not work. Design for single sign-on, sensible defaults, clear errors and manageable key and certificate operations.

Principle 14: Least Functionality

Enable only the services, ports, features and accounts the system needs; remove sample apps, debug endpoints and unused components.

Architecture Exception Register

27002 asks you to document and formally acknowledge controls that do not fully meet requirements. Keep a register:

Security Architecture Review Process

The security architecture review follows this lifecycle:

Identify System → Classify Risk → Apply Principles → Design Review → 
Threat Model → Architecture Decision → Document ADR → Implement → 
Validate → Monitor → Evolve

Step 1: Identify the System and Classify Risk

Document:

• System purpose and business context
• Data types processed (public, internal, confidential, restricted)
• User types and volumes
• Regulatory requirements
• Technology stack
• Integration points
• Deployment model

Risk classification determines review depth:

Step 2: Apply Security Architecture Principles

For each principle, assess the architecture:

Step 3: Design Review

Review the architecture against security best practices:

Authentication Architecture:

• Is there a single, well-managed identity provider?
• Is MFA enforced for all administrative and sensitive access?
• Are session management mechanisms secure (secure cookies, timeout, rotation)?
• Is there account lockout and brute-force protection?
• Is password reset secure and not guessable?

Authorization Architecture:

• Is RBAC or ABAC used consistently?
• Are permissions enforced at every layer (API, service, database)?
• Is there a centralized authorization service (e.g., OPA, CASBIN)?
• Are default permissions deny-all?
• Is there regular access review?

Data Architecture:

• Is data classified and labeled?
• Is encryption at rest used for sensitive data?
• Is encryption in transit enforced (TLS 1.3)?
• Is there data loss prevention (DLP) for sensitive data?
• Is there data retention and deletion policy?
• Is there backup encryption and recovery testing?

Network Architecture:

• Is the network segmented by security domain?
• Is there a DMZ for public-facing services?
• Is internal traffic encrypted (east-west traffic)?
• Is there micro-segmentation for cloud-native services?
• Are firewalls configured with least privilege (default deny)?

Logging and Monitoring Architecture:

• Are security events logged from all layers?
• Is there a centralized SIEM or log aggregation?
• Are logs tamper-evident (immutable storage)?
• Is there real-time alerting for critical events?
• Is there log retention for compliance?

Resilience Architecture:

• Is there redundancy for critical components?
• Is there automatic failover?
• Is there disaster recovery with tested recovery procedures?
• Is there DDoS protection?
• Is there rate limiting and circuit breaking?

Integration Architecture:

• Are API gateways used for external access?
• Is there API authentication and rate limiting?
• Is there input validation at integration points?
• Are third-party integrations isolated and monitored?
• Is there a secure webhook/signature verification?

Step 4: Threat Modeling

Use the threat model (from A.8.26) to validate architecture:

• Does the architecture address all identified threats?
• Are there single points of failure that threats could exploit?
• Can the architecture contain a breach (prevent lateral movement)?
• Are there attack paths that the architecture does not mitigate?

Step 5: Architecture Decision Records (ADRs)

Document major security-relevant decisions:

## ADR-001: Authentication Architecture for Customer Portal

## Status
Accepted

## Context
The customer portal needs authentication for 1 million users. We need to choose between:
- Option A: In-house authentication with custom MFA
- Option B: OAuth 2.0 / OIDC with external identity provider (Auth0, Okta)
- Option C: SAML integration with enterprise SSO

## Decision
Chosen Option B: OAuth 2.0 / OIDC with Auth0

## Rationale
- In-house authentication is complex and error-prone (economy of mechanism)
- Auth0 is a well-tested, audited service with SOC 2 and ISO 27001 certification
- OAuth 2.0 / OIDC is an open standard with broad support
- Reduces development time and security risk
- Supports MFA, social login, and passwordless out of the box

## Consequences
Positive:
- Faster time to market
- Reduced security risk
- Built-in compliance features
- Scalable to millions of users

Negative:
- Dependency on third-party service (vendor risk)
- Ongoing subscription cost
- Data residency considerations (Auth0 data in US/EU)

## Mitigations for Negative Consequences
- Vendor risk assessment and contract review
- Disaster recovery plan for Auth0 outage (local fallback authentication)
- Data processing agreement for GDPR/DPDP Act compliance

## Date
2026-01-15

## Decision Makers
CTO, Security Architect, Product Owner

Step 6: Approval and Implementation

• ARB reviews the architecture, ADRs, and threat model
• Approval is granted with conditions or rejected with feedback
• Security architecture is communicated to development, operations, and security teams
• Architecture is added to the architecture repository

Step 7: Validation and Monitoring

• Security testing validates architecture implementation (penetration testing, architecture review)
• Architecture is monitored for drift (unauthorized changes)
• Security metrics validate architecture effectiveness (vulnerability density, incident containment)
• Architecture is reviewed annually or when significant changes occur

Security Patterns Catalog

Organizations should develop a catalog of security patterns for common scenarios:

Pattern 1: Authentication Pattern

Problem: How to authenticate users securely across multiple applications?
Solution: Centralized OAuth 2.0 / OIDC identity provider with MFA, session management, and token refresh.
Components: Identity Provider (IdP), API Gateway (token validation), Application (token consumption), MFA service.
Security Considerations: Token storage, token expiration, refresh token rotation, MFA enforcement, logout/session invalidation.

Pattern 2: Authorization Pattern

Problem: How to enforce access control consistently across services?
Solution: Policy-based access control (OPA/CASBIN) with centralized policy management and distributed enforcement.
Components: Policy Administration Point (PAP), Policy Decision Point (PDP), Policy Enforcement Point (PEP), Policy Information Point (PIP).
Security Considerations: Policy synchronization, policy evaluation performance, policy versioning, audit logging.

Pattern 3: Encryption Pattern

Problem: How to protect data at rest and in transit?
Solution: TLS 1.3 for all communications, AES-256 for data at rest, envelope encryption with key rotation, HSM or KMS for key management.
Components: TLS termination, KMS, application encryption library, key rotation scheduler.
Security Considerations: Key escrow, key rotation frequency, cipher suite selection, certificate management, HSM availability.

Pattern 4: API Security Pattern

Problem: How to secure API endpoints from abuse and attack?
Solution: API Gateway with authentication, rate limiting, input validation, logging, and WAF integration.
Components: API Gateway, WAF, Rate Limiter, Auth Service, API Analytics.
Security Considerations: Rate limit bypass, API key security, OAuth scope enforcement, CORS configuration, payload size limits.

Pattern 5: Microservices Security Pattern

Problem: How to secure communication between microservices?
Solution: Service mesh (Istio/Linkerd) with mTLS, mutual authentication, authorization policies, and observability.
Components: Service mesh control plane, data plane proxies, certificate authority, observability stack.
Security Considerations: Sidecar resource overhead, certificate rotation, policy enforcement, debugging complexity.

Pattern 6: Data Loss Prevention Pattern

Problem: How to prevent sensitive data exfiltration?
Solution: Data classification, DLP agents, network egress filtering, CASB, and data masking.
Components: Data Classification Engine, DLP Scanner, Egress Firewall, CASB, Data Masking Service.
Security Considerations: False positives, data classification accuracy, encrypted traffic inspection, privacy compliance.

Pattern 7: Zero Trust Network Pattern

Problem: How to secure a cloud-native network without a perimeter?
Solution: Identity-aware proxy, micro-segmentation, device trust, continuous authentication, and behavioral analytics.
Components: Identity-Aware Proxy, Device Trust Service, Micro-segmentation Controller, Behavioral Analytics Engine, SIEM.
Security Considerations: User experience impact, device enrollment, latency, false positives in behavioral analytics.

Pattern 8: Secure Logging Pattern

Problem: How to collect and protect security logs?
Solution: Immutable log storage, centralized SIEM, log integrity verification, tamper-evident logging, and real-time alerting.
Components: Log Shipper, Message Queue, SIEM, Immutable Storage, Alerting Engine, Log Integrity Verifier.
Security Considerations: Log volume, storage cost, log parsing complexity, SIEM rule tuning, privacy in logs.

Architecture for Emerging Technologies

Cloud-Native Architecture Security

• Container Security: Non-root containers, read-only filesystems, minimal images, image scanning, runtime protection
• Kubernetes Security: RBAC, network policies, pod security standards, admission controllers, secrets management
• Serverless Security: Function-level permissions, cold start protection, event injection prevention, resource limits
• Infrastructure as Code: Security scanning of Terraform/CloudFormation (Checkov, tfsec), drift detection, policy as code

AI/ML Architecture Security

• Model Serving: API authentication for model endpoints, rate limiting, model versioning, A/B testing security
• Training Pipeline: Data pipeline security, model artifact signing, access control to training data, experiment tracking security
• Inference Security: Input sanitization, output filtering, adversarial detection, model monitoring for drift
• RAG/Vector DB: Vector database access control, prompt injection prevention, retrieval filtering, embedding security
• MLOps: Secure CI/CD for models, model registry security, deployment approval gates, rollback security

IoT/OT Architecture Security

• Edge Security: Edge device authentication, secure boot, firmware signing, over-the-air update security
• Gateway Security: Protocol translation security, data aggregation validation, gateway authentication
• Cloud Integration: Secure telemetry ingestion, command and control authentication, device provisioning security
• OT/IT Segregation: Purdue model alignment, data diode for unidirectional flow, industrial firewall

Tools, Technologies, and Solutions

Architecture Modeling and Documentation Tools

Architecture Review and Threat Modeling Tools

Infrastructure as Code Security Tools

Service Mesh and Microsecurity Tools

Policy and Procedure Templates

Security Architecture Principles Policy (Template)

Architecture Review Procedure (Template)

Risk Assessment and Treatment

Risk Assessment for Security Architecture

Risk Treatment Options

Audit and Compliance Checklist

Pre-Audit Self-Assessment

Auditor Interview Questions

Be prepared to answer:

1. "What security architecture principles does your organization follow?"
2. "Show me the security architecture review for [system name]."
3. "Who is on the Architecture Review Board?"
4. "How do you ensure architecture principles are followed?"
5. "What happens when a system is deployed without architecture review?"
6. "How do you handle cloud migration architecture security?"
7. "Are there security patterns for common scenarios?"
8. "How do you detect and remediate architecture drift?"
9. "How are architecture decisions documented?"
10. "How do you ensure third-party systems meet your architecture standards?"

Common Audit Findings and How to Avoid Them

Metrics and KPIs

Process Metrics

Outcome Metrics

Dashboard Sample

┌─────────────────────────────────────────────────────────────────────┐
│        SECURE SYSTEM ARCHITECTURE & ENGINEERING DASHBOARD           │
│                    [Organization] — [Month Year]                    │
├─────────────────────────────────────────────────────────────────────┤
│  ARCH REVIEW COVERAGE: 100%  ██████████████████████  Target: 100%  │
│  ADR COMPLETENESS: 96%       ████████████████████░░  Target: 95%  │
│  COMPLIANCE RATE: 92%        ███████████████████░░░  Target: 90%  │
│  PATTERN ADOPTION: 85%       ██████████████████░░░░  Target: 80%  │
│  VULN DENSITY: 1.2           ███░░░░░░░░░░░░░░░░░░  Target: <2   │
│  ARCH INCIDENTS: 0           ░░░░░░░░░░░░░░░░░░░░░  Target: <1/q │
│  REVIEW CYCLE TIME: 5.5 days ████████████████████░░  Target: <7   │
│  EXCEPTION RATE: 3%          ██░░░░░░░░░░░░░░░░░░░  Target: <5%  │
└─────────────────────────────────────────────────────────────────────┘

Common Pitfalls and How to Avoid Them

Pitfall 1: "Architecture Review Slows Us Down"

Symptom: Teams skip architecture review to meet deadlines.

Solution:

• Show time-to-market data: secure architecture reduces firefighting
• Streamline review for low-risk systems (self-assessment + spot check)
• Integrate review into existing design review meetings
• Use reference architecture to accelerate review

Pitfall 2: "Principles Are Too Abstract"

Symptom: Architects don't know how to apply principles to real systems.

Reality: Principles need concrete patterns, examples, and checklists to be actionable.

Solution:

• Create a patterns catalog with concrete implementations
• Provide architecture decision guides for common scenarios
• Use reference architecture as a starting point
• Conduct workshops where architects apply principles to real systems

Pitfall 3: "We Bought the Tool, Now We're Secure"

Symptom: Organization invests in architecture tools but doesn't change processes or culture.

Reality: Tools enable the process; they don't replace governance, training, or accountability.

Solution:

• Invest in process and training alongside tools
• Establish ARB with real enforcement authority
• Track metrics to demonstrate value
• Make architecture review a non-bypassable gate

Pitfall 4: "Cloud Changes Everything"

Symptom: Cloud migration proceeds without architecture review because "cloud is secure by default."

Reality: Cloud is secure by default for the provider's infrastructure, not YOUR architecture. Misconfigured S3 buckets, overly permissive IAM policies, and exposed APIs are the leading causes of cloud breaches.

Solution:

• Mandatory cloud security architecture review
• Cloud-native security patterns (container security, IAM best practices)
• CSPM tools for continuous monitoring
• Cloud security training for architects

Pitfall 5: "Legacy Systems Are Exempt"

Symptom: Legacy systems are not reviewed because "they're too old to change."

Reality: Legacy systems often process the most sensitive data and have the weakest security. Integration with legacy systems can compromise modern architecture.

Solution:

• Review legacy integrations for security impact
• Apply compensating controls where legacy cannot be changed
• Plan legacy modernization with security architecture review
• Isolate legacy systems where possible

Pitfall 6: "Architecture Is Done at the Beginning"

Symptom: Architecture is designed once and never revisited.

Reality: Architecture evolves with threats, technology, and business requirements. Annual review and drift detection are essential.

Solution:

• Annual architecture review for critical systems
• Architecture drift detection (IaC scanning)
• Update principles and patterns with new threats
• Architecture review as part of major change management

Pitfall 7: "We Don't Have Architects"

Symptom: Small organizations lack dedicated architects and skip architecture review.

Reality: Security architecture is a mindset, not just a role. Small teams can use reference architecture, patterns, and lightweight reviews.

Solution:

• Use reference architecture and patterns as starting points
• Conduct peer reviews with security champion
• Use cloud-native managed services (reduce architecture burden)
• Outsource architecture review for critical systems (Singahi offers this)

Pitfall 8: "AI/ML Is Different"

Symptom: AI/ML systems are built without security architecture because "AI is a research problem."

Reality: AI/ML systems have unique architecture risks (adversarial strength, model extraction, data poisoning) but they still need secure architecture.

Solution:

• Use AI/ML security architecture patterns
• Include adversarial testing in architecture validation
• Apply zero trust to model serving and training pipelines
• See the NIST AI Risk Management Framework, ISO/IEC 42001 and the OWASP Top 10 for LLM Applications for specialised guidance

Illustrative Scenarios

Hypothetical scenarios: composite examples for guidance, not real organisations or verified outcomes.

Scenario 1: Microservices Migration Without Service-to-Service Trust

Situation. An e-commerce company splits a monolith into microservices on Kubernetes. A penetration test finds that any service can call any other without authentication, secrets sit in environment files, and there are no network policies.

What applying 8.27 looks like.

1. Principles agreed for the platform: zero trust between services, least privilege, distrust external input, least functionality.
2. A reference architecture: mutual TLS between services, a secrets manager, network policies, an API gateway for external traffic.
3. An architecture review gate for every new service, with decisions recorded as ADRs.
4. Existing services reviewed and fixed in priority order; gaps that cannot yet be closed go in the exception register with compensating controls.

Lesson. Splitting a system into services multiplies trust boundaries. Without service-to-service authentication, a single compromised service reaches everything.

Scenario 2: Multi-Vendor Government Platform

Situation. A state department's citizen-services platform is built by several vendors, each with its own design. Aadhaar-linked data flows through modules with different controls, and no one reviews the architecture as a whole.

What applying 8.27 looks like.

1. A principles policy and a reference architecture covering identity, API security, encryption, logging and data location.
2. The principles written into vendor contracts (27002: apply principles to outsourced development).
3. An architecture review board that reviews each vendor's design against the reference before build, approving, approving with conditions, or rejecting.
4. Drift checks on infrastructure as code, and an annual review of the principles.

Lesson. When many suppliers build one platform, shared principles in the contracts and a single review gate are what keep the security design consistent.

Multi-Framework Mapping

NIST SP 800-53 Rev 5 Mapping

COBIT 2019 Mapping

PCI DSS v4.0.1 Mapping

DPDP Act 2023: Design Implications

OWASP SAMM Mapping

CIS Controls v8 Mapping

Regulatory and Industry Context

India

International

Roles and Responsibilities (RACI)

RACI Matrix for Secure System Architecture

Legend: R = Responsible, A = Accountable, C = Consulted, I = Informed

Role Descriptions

Documentation and Evidence Requirements

Recommended Documentation

ISO 27001 does not mandate specific documents for this control. If you select it, keep the documented information you need to show it is planned and working (clause 7.5), and set retention in your own retention schedule. Typical records:

Evidence for Audit

Continuous Improvement

Improvement Cycle

Plan → Implement → Measure → Review → Improve

Plan: Set targets for architecture review coverage, compliance rate, vulnerability density, incident containment.

Implement: Execute architecture reviews, deploy patterns, train staff, implement automation.

Measure: Track KPIs, conduct surveys, analyze audit results, monitor incidents.

Review: Monthly metrics review, quarterly process review, annual complete review.

Improve: Update principles, refine patterns, adopt new tools, enhance training, integrate emerging technology guidance.

Improvement Triggers

Maturity Advancement Path

FAQ

Q1: Do we need architecture review for cloud-native applications?

A: Absolutely. Cloud-native applications have unique architecture risks (container escape, IAM misconfiguration, API exposure, serverless vulnerabilities). Cloud does not eliminate the need for security architecture, it changes the architecture surface.

Q2: What is the difference between A.8.26 (Application Security Requirements) and A.8.27 (Secure System Architecture)?

A: A.8.26 is about WHAT security the application needs (requirements). A.8.27 is about HOW the system is designed to provide that security (architecture). Requirements come first; architecture implements them.

Q3: How do we handle architecture review in Agile/Scrum?

A: Conduct architecture review during sprint 0 or architecture spikes. Use lightweight ADRs for decisions. Review microservice architecture when adding new services. The review doesn't have to be a 2-week process, it can be a 2-hour workshop for small changes.

Q4: What if we don't have a dedicated security architect?

A: Small organizations can: use reference architecture and patterns as starting points; conduct peer reviews with security champion; use cloud-native managed services (reduce architecture burden); or outsource architecture review for critical systems (Singahi offers this).

Q5: Are there security architecture principles specific to AI/ML?

A: Yes, AI/ML systems need additional principles: model isolation (training vs. inference), adversarial strength, data provenance, explainability, and continuous model monitoring. See the NIST AI Risk Management Framework and the OWASP Top 10 for LLM Applications.

Q6: How do we measure architecture security effectiveness?

A: Track vulnerability density, architecture-related incidents, mean time to contain breaches, compliance audit findings, and architecture drift. See Section 13 for a full KPI framework.

Q7: What is a Zero Trust Architecture?

A: Zero Trust assumes no implicit trust based on network location. Every request is authenticated, authorized, and encrypted. Micro-segmentation, identity-aware proxies, and continuous verification are key components. It is particularly relevant for cloud-native and remote work architectures.

Q8: How do we prevent architecture drift in production?

A: Use Infrastructure as Code (IaC) with scanning tools (Checkov, tfsec), implement drift detection, conduct quarterly compliance checks, and enforce change management for architecture changes.

Q9: What is the role of the Architecture Review Board?

A: The ARB is a governance body that reviews and approves system architectures for security. It ensures consistency, compliance with principles, and alignment with organizational risk appetite. It does not replace individual architect judgment but provides oversight and escalation.

Q10: How do we handle architecture security for legacy systems?

A: For legacy systems, focus on integration security (how they connect to modern systems), apply compensating controls where the architecture cannot be changed, and plan modernization with security architecture review. Do not exempt legacy from architecture review entirely.

Q11: What is an Architecture Decision Record (ADR)?

A: An ADR is a document that captures a significant architecture decision, the context in which it was made, the options considered, the decision rationale, and the consequences (positive and negative). ADRs provide traceability and institutional memory.

Q12: Should we adopt a specific architecture framework (TOGAF, SABSA)?

A: TOGAF and SABSA are enterprise architecture frameworks. For security architecture, you can use them as a structure but the principles and patterns in this guide are framework-agnostic. Start with principles and patterns; adopt a framework if your organization needs enterprise-scale architecture governance.

Q13: How do we handle security architecture for third-party systems?

A: Require vendor architecture documentation, conduct security architecture review of vendor designs, include security requirements in contracts, and verify implementation through acceptance testing and penetration testing.

Q14: What is the relationship between security architecture and DevSecOps?

A: Security architecture provides the design principles and patterns that DevSecOps implements. Architecture review happens before development; DevSecOps tools (SAST, DAST, IaC scanning) validate that the architecture is implemented correctly. Architecture drift detection is a DevSecOps activity.

Q15: How often should we update our security architecture principles?

A: Principles should be reviewed annually and updated when: new technologies emerge, new threats are identified, regulations change, or significant security incidents reveal gaps. Patterns and reference architecture should be updated more frequently (quarterly) to reflect technology evolution.

References and Further Reading

Standards and Guidelines

1. ISO/IEC 27001:2022: Information Security, Cybersecurity and Privacy Protection, Information Security Management Systems, Requirements. ISO, 2022.
2. ISO/IEC 27002:2022: Information Security, Cybersecurity and Privacy Protection, Information Security Controls. ISO, 2022.
3. NIST SP 800-53 Rev 5: Security and Privacy Controls for Information Systems and Organizations. NIST, 2020.
4. NIST SP 800-160 Vol 1 Rev 1: Engineering Trustworthy Secure Systems. NIST, 2022.
5. NIST SP 800-160 Vol 2 Rev 1: Developing Cyber-Resilient Systems: A Systems Security Engineering Approach. NIST, 2021.
6. NIST SP 800-207: Zero Trust Architecture. NIST, 2020.
7. TOGAF Standard, 10th Edition: The Open Group, 2022.
8. SABSA: The SABSA Institute (enterprise security architecture method).
9. OWASP Software Assurance Maturity Model (SAMM) v2.0. OWASP, 2020.
10. CIS Controls v8: Center for Internet Security, 2021.

Security Architecture Books

11. "Security Architecture: Design, Deployment and Operations": Christopher M. King, Curtis E. Dalton and T. Ertem Osmanoglu, McGraw-Hill/Osborne, 2001.
12. "Enterprise Security Architecture: A Business-Driven Approach": John Sherwood, Andrew Clark and David Lynas, CMP Books, 2005.
13. "Zero Trust Networks": Evan Gilman and Doug Barth, O'Reilly, 2017.
14. "Building Secure Software": John Viega and Gary McGraw, Addison-Wesley, 2001.
15. "The Art of Software Security Assessment": Mark Dowd et al., Addison-Wesley, 2006.

Threat Modeling and Patterns

16. "Threat Modeling: Designing for Security": Adam Shostack, Wiley, 2014.
17. "Software Security: Building Security In": Gary McGraw, Addison-Wesley, 2006.
18. "Security Patterns in Practice": Eduardo Fernandez-Buglioni, Wiley, 2013.
19. OWASP Security Knowledge Framework: https://owasp.org/www-project-security-knowledge-framework/
20. MITRE ATT&CK: https://attack.mitre.org/

Indian Regulatory Resources

21. Digital Personal Data Protection Act 2023: Government of India, 2023.
22. RBI Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices: Reserve Bank of India, 7 November 2023 (in force from 1 April 2024); and RBI Cyber Security Framework in Banks: circular of 2 June 2016.
23. SEBI Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities, circular of 20 August 2024.
24. IRDAI Guidelines on Information and Cybersecurity: Insurance Regulatory and Development Authority of India, 2023.
25. Digital India Programme: Ministry of Electronics and Information Technology, Government of India.

Industry Research

26. IBM Cost of a Data Breach Report 2024: IBM Security and Ponemon Institute, 2024.
27. Verizon Data Breach Investigations Report 2024: Verizon, 2024.