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 .
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
postgressuperuserAnd 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
GRANTstatements. Disable the defaultpostgressuperuser. 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 |
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.