# ISO 27001 Secure Architecture Principles

> Document secure system architecture and engineering principles per ISO 27001 Control A.8.27. Produces a principles catalog with rationale, implementation guidance, and technology-stack applicability for development and infrastructure teams.



Tags: ISO 27001, ISMS, Compliance, Secure Architecture, Engineering Principles, A.8.27


## Example Prompts

- Document our secure architecture principles for ISO 27001
- Create a secure engineering principles catalog for our development team
- Validate our architecture principles cover all required categories
- Map secure design principles to our technology stack

URL: https://rakenne.app/skills/iso27001-secure-architecture-principles/index.md

Try this skill: https://rakenne.app/a/?skill=iso27001-secure-architecture-principles



## Overview

ISO 27001 Control A.8.27 requires organisations to establish, document, maintain, and apply secure system architecture and engineering principles to all information system development and infrastructure activities. Auditors expect a documented principles catalog that development and infrastructure teams can reference — not just a general security policy.

This skill produces a principles catalog covering 10 core security architecture categories, each with rationale, technology-specific implementation guidance tailored to your stack, and mapped ISO 27001 controls. A validation tool ensures all categories are covered with substantive guidance, not just headings.

For a step-by-step walkthrough of how this skill fits into the full ISMS flow, see the [**ISO 27001 ISMS workspace tutorial**](/learn/tutorials/iso27001-isms-workspace-guide/).

### What It Covers

- **10 core categories** — defense-in-depth, least privilege, fail-secure defaults, input validation, secure defaults, separation of concerns, audit logging, cryptographic controls, zero trust, and resilience/recovery
- **Technology-specific guidance** — tailored to your cloud provider, programming languages, container platforms, and identity provider
- **Control mapping** — each principle links to specific Annex A controls (A.8.5, A.8.24, A.8.25, etc.)
- **Industry sources** — draws from OWASP, NIST SP 800-160, ISO 27034, NCSC, and CIS benchmarks
- **Applicability matrix** — marks each principle's relevance to cloud, on-premise, development, and infrastructure contexts

## Example Conversation

> **You:** We need to document our secure architecture principles for ISO 27001. We're a GCP-based SaaS company using GKE, Cloud SQL, and Node.js/TypeScript. Our identity provider is Okta.
>
> **Agent:** I'll create a secure architecture principles catalog tailored to your GCP/GKE/Node.js stack. Let me load your organization profile for the full technology context.
>
> I've drafted the catalog with 10 principles, each with implementation guidance specific to your environment. Let me tailor the guidance further before validating.
>
> For example, **Least Privilege** includes:
> - GCP IAM: use predefined roles over basic roles, enforce Workload Identity for GKE pods
> - Okta: scope OAuth tokens to minimum required claims, enforce MFA for privileged roles
> - Cloud SQL: create per-service database users with schema-level grants, no shared `postgres` superuser
>
> And **Cryptographic Controls** includes:
> - GCP CMEK for Cloud SQL and Cloud Storage encryption at rest
> - TLS 1.2+ enforced on all external endpoints via Cloud Load Balancer
> - Secret Manager for API keys and credentials, not environment variables
>
> Let me validate coverage now.
>
> Running **architecture_principles_coverage_check**...
>
> **RESULT: PASS** — All 10 core categories covered with substantive implementation guidance:
>
> | Category | Status | Guidance Quality |
> |----------|:------:|:----------------:|
> | Defense-in-depth | FOUND | Substantive |
> | Least privilege | FOUND | Substantive |
> | Fail-secure defaults | FOUND | Substantive |
> | Input validation | FOUND | Substantive |
> | Secure defaults | FOUND | Substantive |
> | Separation of concerns | FOUND | Substantive |
> | Audit logging | FOUND | Substantive |
> | Cryptographic controls | FOUND | Substantive |
> | Zero trust | FOUND | Substantive |
> | Resilience and recovery | FOUND | Substantive |
>
> All 10 categories have technology-specific implementation guidance (not just generic statements). The document is ready for review and sign-off.

## Sample Output Excerpt

Below is a representative excerpt from a generated principles catalog showing two principle entries.

---

### Secure Architecture Principles Catalog (excerpt)

**ARCH-P02 — Least Privilege / Minimal Authority**

| Field | Value |
|-------|-------|
| **Category** | Access Control |
| **Related Controls** | A.5.15, A.5.18, A.8.2, A.8.3 |

**Description:** Every user, process, and system component operates with the minimum set of privileges necessary to perform its function. No entity receives access by default — access is granted explicitly and scoped narrowly.

**Rationale:** Overly permissive access is the most common root cause of privilege escalation and lateral movement in cloud environments. Least privilege limits blast radius when credentials are compromised.

**Implementation Guidance:**
- **GCP IAM**: Use predefined roles (e.g., `roles/cloudsql.client`) instead of basic roles (`roles/editor`). Bind at project level, not organization level. Enforce Workload Identity for GKE pod-to-service authentication — no exported service account keys.
- **Okta**: Configure OAuth scopes to minimum required claims per application. Enforce step-up MFA for privileged admin roles. Use group-based access policies, not individual assignments.
- **Cloud SQL**: Create per-microservice database users with schema-level `GRANT` statements. Disable the default `postgres` superuser. Use IAM database authentication where supported.
- **Application code**: Enforce RBAC at the API layer. Service-to-service calls use scoped service accounts, not shared credentials.

| Applicability | Cloud | On-Premise | Development | Infrastructure |
|:---:|:---:|:---:|:---:|:---:|
| | Yes | Yes | Yes | Yes |

---

**ARCH-P04 — Input Validation and Sanitization**

| Field | Value |
|-------|-------|
| **Category** | Application Security |
| **Related Controls** | A.8.25, A.8.26, A.8.28 |

**Description:** All data entering the system from external sources is validated, sanitized, and rejected if it does not conform to expected formats. Input validation is applied at the boundary — not delegated to downstream components.

**Rationale:** Input-based attacks (SQL injection, XSS, command injection, path traversal) remain in the OWASP Top 10 and are the primary vector for application-layer compromise.

**Implementation Guidance:**
- **API layer (Node.js/TypeScript)**: Use schema validation libraries (Zod, TypeBox, Joi) on all API endpoints. Reject payloads that don't match the schema — don't attempt to "clean" malformed input.
- **Database queries**: Use parameterized queries exclusively (Cloud SQL client libraries enforce this). Never construct SQL from string concatenation.
- **File uploads**: Validate file type by magic bytes (not extension), enforce size limits, and store in Cloud Storage with content-type restrictions.
- **Output encoding**: Apply context-aware encoding (HTML entity, URL, JavaScript) in all rendered templates to prevent XSS.

| Applicability | Cloud | On-Premise | Development | Infrastructure |
|:---:|:---:|:---:|:---:|:---:|
| | Yes | Yes | Yes | No |

<!-- /excerpt -->

## Extension Tools

### `architecture_principles_coverage_check`

Validates the principles catalog covers all 10 core security architecture categories:

| # | Category | What It Checks |
|:-:|----------|----------------|
| 1 | Defense-in-depth / layered security | Multiple defensive layers, network segmentation |
| 2 | Least privilege / minimal authority | Minimum necessary access, role scoping |
| 3 | Fail-secure / fail-safe defaults | Secure failure modes, default-deny behavior |
| 4 | Input validation and sanitization | Boundary validation, injection prevention |
| 5 | Secure defaults / security by default | Hardened initial configurations |
| 6 | Separation of concerns | Environment isolation, compartmentalization |
| 7 | Audit logging and monitoring | Security event capture, SIEM integration |
| 8 | Cryptographic controls | Encryption at rest/in transit, key management |
| 9 | Zero trust / verify explicitly | No implicit trust, continuous verification |
| 10 | Resilience and recovery | Fault tolerance, graceful degradation |

For each found category, the tool also verifies that **substantive implementation guidance** exists (30+ words with specific technology or action indicators) — not just a heading or single-sentence placeholder. Reports per-category status and overall PASS/FAIL.

## Getting Started

Activate the *ISO 27001 Secure Architecture Principles* skill. If you've completed the *Organization Profile* skill, load it — the agent uses your technology stack to tailor implementation guidance to your specific cloud provider, languages, and tools.

Have this information ready:
- Your cloud provider(s) and key services (e.g., GCP GKE, AWS EKS, Azure AKS)
- Programming languages and frameworks used
- Identity provider (Okta, Azure AD, Google Workspace)
- Container or orchestration platforms
- Any existing security standards or coding guidelines your team follows

The agent drafts a complete principles catalog, tailors guidance to your stack, validates coverage of all 10 categories, and produces a document ready for review by development and infrastructure leads.



---

Back to [Skill Library](https://rakenne.app/skills/index.md)